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Volume I: Technical Assessment Report 

1.0 Notifi cation and Authorization 

A NASA Engineering and Safety Center (NESC) out-of-board assessment was approved on 
October 5, 2006. Mr. Cornelius Dennehy, NASA Technical Fellow for Guidance, Navigation 
and Control (GN&C) was selected to lead this assessment. The Assessment Plan was presented 
and approved by the NESC Review Board (NRB) on April 19, 2007. The Study Kickoff meeting 
was held at Massachusetts Institute of Technology (MIT) on April 20, 2007. Interim research 
project progress and status reviews were held at MIT in July 2007, in December 2007 and in 
March 2008. An Initial Summary was presented to the NRB on December 19, 2008. The Final 
Report was presented for approval to the NRB on October 22, 2009. 

The key stakeholders for this assessment are Mr. Frank Bauer, Chief Engineer for the 
Exploration Systems Mission Directorate (ESMD); Dr. Brian Muirhead, Constellation Program 
(CxP) Chief System Engineer; Mr. Howard Hu, Orion Crew Exploration Vehicle (CEV) GN&C 
lead; Mr. Scott Tamblyn, CEV GN&C Engineering; and Mr. William Othon, CEV GN&C 
Engineering. 

The NESC, MIT, and Draper Laboratory team performed an independent and systematic study 
on the problem of optimizing the reliability of GN&C architectures with common avionic units. 
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4.0 Executive Summary 

This final report summarizes the results of a comparative assessment of the fault tolerance and 
reliability of different Guidance, Navigation and Control (GN&C) architectural approaches. 

This study was proactively performed by a combined Massachusetts Institute of Technology 
(MIT) and Draper Laboratory team as a GN&C “Discipline-Advancing” activity sponsored by 
the NASA Engineering and Safety Center (NESC). This systematic comparative assessment of 
GN&C system architectural approaches was undertaken as a fundamental step towards 
understanding the opportunities for, and limitations of, architecting highly reliable and fault 
tolerant GN&C systems composed of common avionic components. The primary goal of this 
study was to obtain architectural ‘rules of thumb’ that could positively influence future designs 
in the direction of an optimized (i.e., most reliable and cost-efficient) GN&C system. A 
secondary goal was to demonstrate the application and the utility of a systematic modeling 
approach that maps the entire possible architecture solution space. 

The NESC team implemented a systematic approach for modeling, enumerating, and comparing 
simplified GN&C architectures using basic metrics. GN&C systems were decomposed into 
simple ‘building block’ subunits of Sensors, Computers, and Actuators, and various forms of 
subunit interconnection were defined for investigation. The resulting subunit/interconnection 
construct was used as a top-level abstraction for building candidate GN&C system architectures. 
This model was implemented using MIT’s Object Process Network (OPN) modeling language to 
more easily enumerate possible architectures, and ultimately identify which of these architectures 
have optimal properties. Dual and triple redundant GN&C system architectures, employing 
different reliability classes of components, were modeled using the OPN language. For the 
purpose of simplicity, it will be assumed that there are only three different types of GN&C 
avionic components possible for each component class. For example, the model incorporated 
three different types of GN&C Sensor components generically labeled Type A, Type B, and 
Type C, but understood to be representative of a low reliability/lightweight/low accuracy Sun 
Sensor; a medium reliability/medium weight/low-to-medium accuracy star tracker; and a high 
reliability/high weight/high accuracy Inertial Measurement Unit (IMU). The team assessed the 
avionic components typically used to implement recent space system GN&C architectures. 

Based upon this assessment, the team made a critical modeling assumption that the more reliable 
GN&C components tended to be heavier, more costly, and/or more complex. The team realized 
there are other modeling assumptions that could have been made, such as the GN&C avionic 
component with the smallest part count is a more reliable (and probably lower mass) unit than 
one with a higher part count. However, that alternate model construct did not fit either the 
team’s desire to keep the model simple and tractable, or the attributes of the GN&C avionic 
component inventory/technology base. 
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For the purposes of this study, reliability is defined as the probability that a given item will 
perform its intended function for a given time under a given set of flight conditions. This is most 
often expressed in terms of an average or mean life, such as Mean Time Between Failure 
(MTBF). Individual component reliabilities are dependent upon the component failure rate and 
desired operational time. The reliability relationships used in the model were exponential and 
governed by the equation R = e ' Xt , where A is the failure rate and t is the operational time. 
Operational time is a user-defined parameter and based on the length of the space exploration 
mission. An operational time of t = 10 years was assumed in the models developed. It should be 
noted that the model assumed perfect coverage - 100-percent - accuracy in detecting and 
isolating a failure. 

All enumerated architectures were evaluated based on two specific metrics: reliability and 
weight. In this study, the team elected to assume weight as a surrogate indicator of system cost 
and complexity. The team acknowledges that in some cases system cost can be driven by the 
complexity factor alone. However to keep the model simple for this top-level study, the 
assumption made was that weight is a good first-order approximation for system complexity and 
cost. 

The team used an interconnection construct as a top-level abstraction for building a preliminary 
model of GN&C system architectures. This model was implemented using the OPN modeling 
language in order to more easily enumerate possible architectures and ultimately identify which 
architectures have optimal properties. Partial 2x2 systems (i.e., systems with up to dual 
redundancy per component class for two component classes) and 3x2 systems (i.e., systems 
with up to triple redundancy per component class for two component classes) were modeled in 
OPN. Within the constraints of these models, all possible architectures were rigorously 
enumerated and the weight/reliability trade-offs of cross-strapping components and using more 
than one type of component was assessed. 

It was found that more reliable components are only beneficial in single string systems, or 
systems with single point failures. The key finding of this study was that most optimal GN&C 
system architectures employing component redundancy can be produced from generic 
connections and the least reliable type of avionic component from each component class. The 
analysis of the identified optimal architectures show that it is possible to produce nearly all 
potentially optimal architectures using only the Type A light weight/low-reliability Sensors, 

Type A light weight/low-reliability Computers, and generic connections. The identified optimal 
architectures reveal a preference to increase GN&C system redundancy of lighter, less reliable 
components rather than using smaller numbers of more reliable, heavy components. 
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The NESC team concluded there is merit in mapping the entire possible system architecture 
solution space. By showing where similar classes of solutions fall within the entire set, it allows 
one to quantitatively see how certain solution features affect Figure-of-Merit (FOM) 
performance and derive architecture ‘rules of thumb’. It also allows one to see the optimal 
system architecture solution boundary (the Pareto Front) and understand how one FOM can be 
exchanged for another. 

The approach documented in this report provides insight into a potential limitation of the 
‘Minimum Functionality/Minimum Implementation’ system architecting methodology also 
known as the ‘Iterative Risk Driven Design Approach ‘as described in [ref.6] which uses as its 
starting point a single-string non-redundant system architecture. This method involves 
performing iterative trades to improve system safety until the mass margin is exhausted. It is not 
apparent that this stepwise optimization of a single design can ever achieve the boundary of 
optimal solutions (the Pareto Front). Even if it somehow did reach the optimal boundary, it is 
not clear the system architects will have access to and be able to visualize the whole range of 
optimal solutions. System architects using the ‘Minimum Functionality/Minimum 
Implementation’ approach should be aware of the technique described in this report and consider 
using it for comparison. 

The team also concluded that with some enhancements, the systematic GN&C/ Avionics 
“building block” OPN modeling techniques employed would serve as an excellent tool for 
evaluating competing GN&C system architectures for future spacecraft. This OPN-based 
approach, or other similar modeling tools, would perform the extremely useful up-front function 
of identifying the most attractive (lowest weight and overall “cost”) GN&C architectural options 
that satisfy a prescribed set of spacecraft fault tolerance, reliability, and performance 
requirements. Although less likely, but worth observing, is that such “building block” models 
could be used to identify the optimal (highest reliability/lowest weight) architectural options for 
a prescribed number and configuration of connections between adjacent GN&C components. 
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5.0 Ass essment Plan 

5.1 Background 

Historically, the United States (US) human spaceflight programs have had thorough GN&C 
analysis and design early in their lifecycles, evaluating various GN&C architectural concepts 
within the trade space of their individual mission goals, constraints, and risk postures. The 
selected GN&C architectures have been tailored for each program, which is not surprising given 
the very different mission concepts. The Constellation Program (CxP) will be no different, but 
top level program requirements drivers for reliability and affordability may flow down to 
influence GN&C architectural considerations, such as fault tolerance, in ways never before 
encountered in the US space program. 

Accomplishing the objectives of the CxP requires reliable GN&C for multiple spacecraft, both 
crewed and robotic. The up-front “architecting-in” of reliability is an integral part of the early 
steps of the GN&C Systems Engineering process. Substandard architectures may not only be 
unreliable but are typically difficult to fabricate, test, operate, support, service, and upgrade. 
These architectures can also be prohibitively costly to adapt to evolving mission scenarios as the 
system lifecycle extends beyond the anticipated time frame of service. 

The operators of systems with substandard architectures can have protracted development 
schedules and high recurring operational costs as a result of not fully informed design decisions 
made early in a project’s development cycle. Therefore, it was important that a major system 
development project not prematurely shift its focus to the challenges of implementation before 
fully defining the appropriate architecture. There is benefit to allocating the time and devoting 
sufficient attention to defining the optimum system architecture over the lifecycle by producing 
the maximum return for a given level of risk and resources. 

With some of these considerations in mind a comparative assessment activity focused on 
investigating the fault tolerance and reliability trades between different GN&C architectural 
approaches was formulated by the NASA Technical Fellow for GN&C. This led to a proactive 
study being performed by a combined MIT and Draper Laboratory team as a GN&C “Discipline- 
Advancing” activity sponsored by the NESC. The motivation for performing this study was the 
observation, both on the part of NESC and MIT, that GN&C systems for exploration 
prominently stand out among all the future spacecraft systems, as a potential “sweet spot” area 
where having flight hardware commonality might be of greatest benefit. This systematic 
comparative assessment of GN&C system architectural approaches was undertaken as a 
fundamental step towards understanding the opportunities for and limitations of architecting 
highly reliable and fault tolerant GN&C systems composed of common GN&C avionic 
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components. The primary goal of this study was to obtain architectural ‘rules of thumb’ which 
could positively influence and drive future designs in the direction of the most reliable and cost- 
efficient GN&C systems possible. A secondary goal was to demonstrate the application and 
utility of a systematic modeling approach that maps the entire possible architecture solution 
space. 

5.2 Scope 

The proposed work was a systematic GN&C architecture comparative study performed by an 
integrated MIT/Draper Laboratory study team under the leadership of Dr. Edward Crawley of the 
MIT Aeronautics and Astronautics Engineering Department. 

This study leveraged analytical methods developed at MIT as part of their program in Technical 
System Architecture, and their specialized analysis tools/methods used to support the NASA 
Exploration Systems Mission Directorate (ESMD) Concept Exploration and Refinement 
(CE&R) study. The MIT tools and methods were extended and applied to the problem of 
optimum GN&C system architectures. The existing MIT systematic architecture analysis 
capability, under Dr. Edward Crawley, was used to execute this task. Dr. Steven Hall, formerly 
of the Draper Laboratory, actively participated in this assessment as the Co-Lead and as the 
principal researcher on the assessment and evaluation of reliable GN&C avionic architectures. 

MIT’s capabilities in system architecting methods were grounded in long-term research studies 
and benchmarking of best practice in space, automotive, electronics, and oil exploration 
industries. Historical work included methods developed in support of NASA’s Advanced 
Planning and Integration office, the creation and continuous refinement of a graduate-level class 
in Technical System Architecture, and through participation in multiple previous studies 
supporting NASA’s ESMD. 

6.0 Problem Description, Proposed Solutions, and Risk Assessment 

6.1 Description of the Problem 

Sensors, Computers, and Actuators will be defined as “component classes”. The terminology “I 
x J OPN model” will be used to describe a model with up to “I” redundancy per component class 
and up to “J” component classes. For example, J = 2 could designate a model which only has 
Sensors or which has Sensors and Computers. J = 3 could designate a model with: Sensors; 
Sensors and Computers; or Sensors, Computers, and Actuators. If J = 3 and 1 = 2, this could 
designate a system with up to 2 Sensors, 2 Computers, and 2 Actuators. This paper will discuss 
the OPN 2x2 and 3x2 models and their applicability to a 3 x 3 model. 
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For the purpose of simplicity, it will be assumed that there are only three different types of 
components possible for each component class. In reality, three Sensor Types might include a 
Sun Sensor, star tracker, and an IMU. However, to be more generic, Types will instead be 
referred to as Type A, Type B, and Type C. 

As a first pass, all enumerated architectures were evaluated based on two specific metrics: 
reliability and weight. In this study, the team elected to use weight as a surrogate indicator of 
system cost and complexity. The team did observe and understand that in some cases system cost 
can be driven by the complexity factor alone. However to keep the model simple for this top- 
level study the assumption made was that weight is a good first order approximation for system 
complexity and cost. 


7.0 Data Analysis 

Section 7.1 will discuss the design of the simple 2x2 model, Section 7.2 will give further details 
on the model, and Section 7.3 will discuss the design of the more complicated 3x2 model. 
Section 7.4 will examine the application of reliability and weight metrics to the enumerated 
architectures. Finally, Section 7.5 will provide some general concluding remarks. 

7.1 The 2 x 2 GN&C System 

This section begins the discussion of the design of the 2 x 2 model. Even with just four 
components (2 Sensors and 2 Computers), numerous architectures can be defined for a 2 x 2 
system based on how the components are inter-connected. Each of these architectures will have 
different total weight and reliability. 



Owrelizec Hvwid Cross-Siapped 


Figure 7.1-1. Three Possible 2 x 2 Systems 

Figure 7.1-1 depicts three possible 2x2 architectures. The reliability, R, of the three models is 
shown in Table 7-1.1, where s, is the reliability of Sensor j, and Ck is the reliability of 
Computer k. 
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Table 7.1-1. Reliability Expressions for the 2x2 Systems in Figure 7.1-1 


Architecture Relh 

ibility 

Channelized 

R = SiCi + S2C2-S1C1S2C2 

Hybrid 

R = S1C1 + S2C1 + S2C2 — S2C1C2 — S1S2C1 — 

S1S2C1C2 + S1S2C1C2 

Cross-Strapped 

R = S1C1 + sic 2 - S1C1C2 + s 2 ci + s 2 c 2 - s 2 cic 2 - 

S1S2C1 — 2S1S2C1C2 + 2S1S2C1C2 — S1S2C2 + 
2S1S2C1C2 — S1S2C1C2 


It is important to note that no matter what the architecture, the reliability of any 2 x 2 model can 
be generated by taking the cross-strapped expression for R and then eliminating terms from the 
expression for connections which do not exist and therefore do not contribute to system 
reliability. Additional indicator variables are added to the cross-strapped reliability expression to 
specify which terms to eliminate. These indicator variables were correlated with the 
interconnections between components. A nonzero indicator variable represented a connection, 
whereas an indicator variable equal to zero represents a missing connection. 

Using the methodology described, the following general expression for R is obtained: 

R = SlillCi + SP12C2 - Siinii2CiC2 + S2i2lCi + S2i22C2 - S2i2li22ClC2 - S^ill^lCi - 
SiS2illi22ClC2 - SiS2il2i2lClC2 + S^il lil2i2lClC2 + SiS2illi2li22ClC2- SiS2il2i22C2 + 
SlS2illil2i22ClC2 + S 1 S2i 1 2i2 1 i22C l C2 - SiS2il lil2i2li22ClC2 

Where ijk is the reliability of the connection between Sensor j and Computer k, if such a 
connection exists and 0 otherwise. 

As a sanity check, the reliability expressions for the channelized and hybrid architectures can be 
derived from the general expression. Assuming perfect connection reliability (i.e., ijk = 1 for all 
connections in the architecture) the channelized and hybrid architectures would be represented 
by the indicator variables in Table 7 . 1 - 2 . Plugging these indicator variables into the general 
expression gives the same reliability expressions in Table 7 . 1 - 1 . 

Table 7.1-2. Indicator for the Channelized and Hybrid 2 x 2 Systems in Figure 7.1-1 


Architecture i 

11 

il2 

121 

122 

Channelized 

100 1 




Hybrid 

10 11 
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7.2 Details on the 2x2 OPN Model 

Like the previously mentioned 3x2 and 3x3 models, the 2x2 OPN model was viewed as a 
sophisticated Petri net model. In a Petri net model, information-storing tokens move via directed 
arcs from transitions to and from places to transitions. Note that there may be more than one 
directed arc feeding from or to a transition or place. Upon arrival at a transition a token is 
consumed and then processing is completed, and, if appropriate, new tokens were introduced in 
the places dictated by the directed arcs leading from the transition. 

The sequence of transitions in any of the discussed OPN models is a sequence of decision points. 
At each decision point, a token is replicated with multiplicity equal to the number of possible 
decisions. The information stored in each token represents a unique possible architecture. Taken 
together, the tokens enumerate all possible architectures given an initial set of constraints. All 
tokens are collected when they completely propagate through the model for analysis. 

Figure 7.2-1 is a visual representation of the OPN decision tree for the 2 x 2 model and the 
following questions are the decision points: 

• How many Sensors? 

■ 1 or 2 

• Type assignment for Sensors? 

■ If only one Sensor, then choose Sensor A, Sensor B, or Sensor C 

■ If two Sensors, then choose two of the same Type of Sensor or one of each of two 
Types (i.e., the possible combinations would be: AA, AB, AC, BB, BC, and CC) 

• How many Computers? 

■ 1 or 2 

• Type assignment for Computers? 

■ If only one Computer, then choose Computer A, Computer B, or Computer C 

■ If two Computers, then choose two of the same Type of Computer or one of each 
of two Types (i.e., the possible combinations would be: AA, AB, AC, BB, BC, 
and CC) 

• Which Sensors are connected to Computer 1? 

■ Just Sensor 1 

■ Just Sensor 2 (if Sensor 2 exists) 
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■ Both Sensor 1 and 2 (if Sensor 2 exists) 

• If Computer 2 exists, which Sensors are connected to Computer 2? 

■ Just Sensor 1 

■ Just Sensor 2 (if it Sensor 2 exists) 

■ Both Sensor 1 and 2 (if Sensor 2 exists) 
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Figure 7.2-1. 2x2 OPN Decision Tree 

During the process of token propagation, the number of components, component types, and 
connections were continuously updated for later use in reliability calculations. In addition, the 
current weight of the system was updated at execution time. Each component type was given its 
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own unique reliability and weight based on the specific make and model of the component. 
These values were based on real components, but modified slightly to facilitate analysis. 
Reliabilities are dependent upon the failure rate of the component and the desired operational 
time for the component. The relationship is governed by the equation R = e ' Xt , where A is the 
failure rate and t is the operational time. Operational time is user defined and based on the 
length of the proposed mission. An operational time of t = 10 years was used in the models 
discussed in this paper. Other component properties are illustrated in Table 7.2-1 and Table 
7.2-2. 


Table 7.2-1. Component Properties For Sensor Types A, B, and C 


Sensor Type 

AB 


C 

Failure Rate, X (/year) 

0.00015 0.00 

01 

0.00005 

Reliability, R 

0.9985 

0.999 

0.9995 

Weight (dimensionless) 

3 

6 

9 


Table 7.2-2. Component Properties For Computer Types A, B, and C 


Computer Type 

AB 


C 

Failure Rate, X (/year) 

0.0001 0.00 

004 

0.00002 

Reliability, R 

0.999 

0.9996 

0.9998 

Weight (dimensionless) 

3 

5 

10 


Two additional weights and one reliability were also included in the model. A “connection 
weight” and a “dissimilar component penalty” were included to ensure that weight continues to 
approximate complexity and cost. Cross-strapping components may not add significant weight 
to the overall system, but adds to the system complexity and cost. Similarly, dealing with more 
than one Type of Sensor and/or Computer also increases complexity and cost. Hence, adding 
these additional weights where appropriate worked as a first step toward simulating an 
operational system. 

The weights associated with connections and dissimilar components were chosen to be consistent 
with the weights of Sensors and Computers. To do so, assumptions were made and the 
connections were considered to be, at most, 1/3 of the complexity of the average Computer. In 
addition, the weight penalty for dissimilar components was set such that it was not larger than 
the heaviest Sensor or Computer. 

These assumptions dictated a certain range of weight values used for connections and dissimilar 
component parameters. However, rather than presuppose exact values for these weights, 
multiple OPN runs were executed varying one of the parameters each time. Assuming the 
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connection reliability would be greater than that of a Computer, the nine OPN scenarios are 
illustrated in Table 7.2-3. 

Table 7.2-3. Connection Reliabilities, Connection Weights, and Dissimilar Component Penalties for 

Each OPN Scenario Run 


OPN Scenario 

1 2 


3 

4 

5 

6 

7 

8 

9 

Connection 

Reliability 

1 1 


1 

0.99995 

0.99995 

0.99995 

0.9999 

0.9999 

0.9999 

Connection 

Weight 

(dimensionless) 

0 

0 

0 

0.5 

0.5 

0.5 

5/3 

5/3 

5/3 

Dissimilar 

Component 

Penalty 

(dimensionless) 

06 


9 

0 

6 

9 

0 

6 

9 


7.3 Details on the 3x2 OPN Model 

Implementation of the 3 x 2 OPN model is similar to that of the 2 x 2 model with two notable 
exceptions. These exceptions relate to the overall system reliability formula and the removal of 
duplicate architectures to minimize the computer memory required to run the model. The 
reliability formula was more complicated for the larger models and was handled differently. 
Although reliability is calculated after the OPN completes execution, it can no longer be easily 
manually calculated for implementation in Microsoft® Excel®. Instead, symbolic MATLAB® 
was used to calculate the formula and a MATLAB® script was used to insert the correct “i” 
indicator values where appropriate. Only after this manipulation was performed could the 
reliability values be imported into Excel® for implementation. 

In addition, care had to be taken to ensure no architecture was represented more than once in the 
model. Running a larger 3x2 OPN model would take an inordinate amount of time and 
computer memory. It was found that certain architectures could be represented in multiple 
configurations and this was not taken into account by the 2x2 model 1 . By producing tokens for 
all possible configurations of the same architecture, the model required significantly longer run 
times and used substantial memory. 


1 The 2x2 model is smaller than the 3 x 2 model. As a result, there were no memory issues and duplicate 
architectures were removed in post-processing (i.e., they did not have to be removed in OPN). 
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An example of duplicate architecture is shown in Figure 7.3-1. A1 and A2 represent the same 
architecture, in both cases one Sensor of Type A is connected to a Computer of Type A, the other 
Sensor A is connected to a Computer A and a Computer B, and a Sensor of Type B is connected 
to a Computer of Type C. A3 represents a different architecture, however, since both Sensors of 
Type A are connected to a Computer of Type B. 


A1 A2 A3 


A 


A, 


A 



A 


A 

1 r * .. i 4i 1 



ikd 7 “ 







1 i 


A 

A 

fit-ior 7 |i.r.Tiru:rr 2\ 

B 

— 

A 

1 Sensor 2 

K ^Gummier 21 1 

B 

| = 

A 

1 Sensor 2 

1^— ^crontet 2t 

E 

B 

. f-r-.tnr 3 | ICa-ipUIer 3J 

C 


i 

1 Sfinscr 3 


C 


B 

1 Sensor 3 

1 IConptlEt 31 

C 


Figure 7.3-1. Determination of Duplicate Architectures 

The process of eliminating duplicate architectures began by choosing a representative set of 
Sensor Types and Computer Types. Ten possibilities were chosen as representative orderings of 
the three Sensor Types and also the three Computer Types: AAA, AAB, AAC, ABB, ACC, 

ABC, BBB, BBC, BCC, and CCC. 

A1 in Figure 7.3-1 represents a connection pattern between three adjacent components. This 
connection pattern has four connections: Sensor 1 to Computer 1, Sensor 2 to both Computer 1 
and Computer 2, and Sensor 3 to Computer 3. Keeping this connection pattern fixed, the team 
gave a “Type” identity to the three Sensors based on the 10 possible orderings. For each possible 
ordering of the Sensor Types, there were 10 possible orderings of the Computer Types, each of 
which defines a unique architecture. In other words, for any given connection pattern such as 
Al, there are 10 x 10 = 100 possible architectures. The OPN model iterates through all possible 
connection patterns and finds all 100 possible architectures. 

Note that orderings such as ABA and BAA are not taken to be representative orderings. When 
all possible connection patterns are taken into account, these additional orderings will fail to 
produce any architecture that cannot be produced by AAB. This is because ABA, BAA, and 
AAB are equivalent (i.e., all represent two components of Type A and one of Type B). It does 
not matter in what order the Types are described as long as the case is represented. 

Searching for duplicate architectures in the OPN does not require checking 100 possible 
architectures for each connection pattern. The 100 possibilities for each connection pattern can 
be represented by 16 representative architectures. As illustrated in Figure 7.3-2, the 10 Sensor 
Type combinations and the 10 Computer Type combinations can be abstracted to just four 
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representative combinations per component. First, AAA, BBB, and CCC represent the case 
where all three components are of the same type. Next, AAB, AAC, and BBC represent the case 
where the first two components were of the same Type and the third component was of a 
different Type. Furthermore, ABB, ACC, and BCC represent the case where the second and 
third components are of the same Type, but the first component is of a different Type. Finally, 
ABC represents the case where all three components were of a different Type. 
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Figure 7.3-2. Finding Representative Architectures 
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Figure 7.3-3 helps demonstrate why these representative architectures work for finding duplicate 
architectures. To use representative architectures to find duplicates is to claim that if architecture 
A1 is equivalent to architecture A2, but not A3, then architecture B1 is equivalent to B2, but not 
B3. 
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Figure 7.3-3. Using Representative Architectures to Find Duplicates 


As previously discussed, A1 and A2 represent the same architecture even though they have 
different connection patterns. It is arbitrary which form of architecture is chosen as the primary 
form and which is a duplicate (i.e., either A1 or A2 could be considered the duplicate). 

The study team implemented duplicate detection into the model, which was an involved manual 
process. The assessment had a finite schedule allocation and the development time necessary for 
automating the duplicate detection process was uncertain. It was therefore decided that a manual 
(i.e., brute force) method should be used to implement duplicate detection. All possible 
representative architectures were manually drawn and duplicate architectures were identified. In 
all, over 100 pages of architectures were drawn and compared. An example of manually drawn 
architectures is shown in Figure 7.3-4. 
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Figure 7.3-4. Example of Manually-Drawn Architectures 


Based on the circled representative architectures, rules were created and inserted into the OPN to 
keep any tokens that will produce duplicate architectures from propagating. Note that all rules 
are in the form of Boolean expressions starting with “not if’ instead of “if’. Although all work 
was double-checked, it is conceivable that an incorrect rule was entered due to human error. By 
using “not if’ instead of “if ’, the default is to pass the token. It was assessed that it is better to 
retain a duplicate architecture rather than exclude a potentially optimal architecture. 
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The Boolean rules are inserted into the OPN model on the transitions from: 

• Which Sensors are connected to Computer 1? 

• If Computer 2 exists, which Sensors are connected to Computer 2? 

• If Computer 3 exists, which Sensors are connected to Computer 3? 

To the places: 

• Just Sensor 1 

• Just Sensor 2 (if Sensor 2 exists) 

• Just Sensor 3 (if Sensor 3 exists) 

• Just Sensors 1 and 2 (if Sensor 2 exists) 

• Just Sensors 1 and 3 (if Sensor 3 exists) 

• Just Sensors 2 and 3 (if Sensor 3 exists) 

• Sensors 1, 2, and 3 (if Sensor 3 exists) 

Trivial rules govern which Sensors are connected to Computer 1 . If a particular token represents 
an architecture with only two Sensors, it is not possible to make a connection to a Computer 
from a nonexistent Sensor 3. Therefore, in the two Sensor case, no new tokens are introduced 
into the places representing, “just Sensor 3”, “just Sensors 1 and 3”, “just Sensors 2 and 3”, or 
“Sensors 1, 2, and 3”. Similarly, if a particular token represents an architecture with only one 
Sensor, no new tokens are introduced into the places representing, “just Sensor 2”, “just Sensor 
3”, “just Sensors 1 and 2”, “just Sensors 1 and 3”, “just Sensors 2 and 3”, or “Sensors 1, 2, 
and 3”. 

Rules governing connections to Computer 2 and 3 are more complicated. If a token represents 
an architecture with only two Computers, the final system architecture will be evident after 
creating the Sensor connections to the second Computer. If a token represents an architecture 
with three Computers, it is known that there will be a final system architecture after creating the 
Sensor connections to the third Computer. Connections that will form duplicate (circled) 
architectures should not be allowed to propagate. Hence rules are followed to block introduction 
of these tokens. 

Figure 7.3-5 shows an example of a rule based on a manually drawn architecture. This rule 
determines whether a connection should be made between Sensor 3 and Computer 3. Note that, 
by the time a token reaches the given rule, the connections between Sensor 1 and Computer 2, 
and between Sensor 2 and Computer 1 have already been defined. No connection should be 
made if the type definitions for the Sensors and Computers match those represented by the 
circled architectures (i.e., such tokens will result in the formation of duplicate architectures). 

In other words, the connection between Sensor 3 and Computer 3 should not be made if Sensor 
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1 ’s Type is the same as Sensor 2’s Type, or Computer 1 ’s Type is the same as Computer 2’s 
Type. 
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e a e 
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C — C 


! (Computer Redundancy < 3) && 

! (Sensor Redundancy < 3) && 

! ( 

(ill == 0 ScSc il2 == 0) || 

(Sensor Redundancy > 1 && i21 == 0 && i22 == 0) | | 

( 

(ill == 0 && il2 > 0 ScSc i 21 > 0 ScSc i 22 == 0 ScSc i31 = = 
0 && i32 == 0) && 

( 

( Sensor l_Type == Sensor2_Type) | | 

( Computer l_Type == Computer2_Type) 

) 


Figure 7.3-5. Example of Rule Based on a Manually Drawn Architecture 

Eliminating duplicate architectures in the 3 x 2 OPN model significantly reduced the number of 
tokens produced from 51,902 to 9,795 tokens. 
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7.4 Results 

Despite eliminating the unnecessary duplicate architectures from the model, attempts to run a 
3x3 model still resulted in a memory shortage. Although it is unfortunate that the larger OPN 
model could not be completed, it is important to note that results from the 3 x 2 model can be 
applied to the 3 x 3 case. 

By taking a top-level view of a GN&C system, the interaction between adjacent Sensor and 
Computer components is identical to the interaction between adjacent Computer and Actuator 
components. Similar to the Sensors and Computers, there are different Types of Actuators, each 
with a unique set of properties. A system architect will be able to choose different redundancies 
for each of these Types. Furthermore, the connection patterns already found between Sensors 
and Computers are the same as those between Computers and Actuators. Finally, the metrics of 
weight and reliability can be calculated in the same way. 

There were nine scenarios outlined in this section, each scenario was run and Pareto plots were 
produced for each. Representative plots for the nine scenarios are reproduced in Figures 7.4-1 
through 7.4-4. In each scenario, the architectures that simultaneously had both lowest weight 
and highest reliability were identified. These architectures are “on the Pareto front.” The 
identified Pareto- architectures were found by zooming in on the “utopia point” at the lower right 
hand comer of the plot 2 . Note that in most cases, there are multiple identified architectures for 
each scenario since it is somewhat subjective which architectures are closer to the utopia point. 
For example: Is an architecture with weight =17 and reliability = 0.999999596912468 (six “9”s) 
better than an architecture with weight =18 and reliability = 0.999999995634079 (eight “9”s)7 

The answers to such questions are made clear in the mission requirements context. For a human- 
rated mission, perhaps a reliability of 0.9999999 (seven “9”s) is required for safety. If this were 
the case, the architecture with weight =18 would be better, since the architecture with weight = 
17 does not meet the seven “9”s requirement of this example. 

In the zoomed out (top) plot of each of the nine scenarios, there appear to be six clusters of 
architecture data points. The architectures in each cluster have nearly identical reliabilities. 
Looking from left to right, the first five clusters (i.e., the five clusters with the lowest reliability) 
are driven by single point failures of any of the six component Types. For example, in an 
architecture that contains one Sensor and two Computers, or an architecture that contains one 
Sensor and three Computers, the single Sensor present in the architecture must remain viable in 
order for the overall system to remain reliable. Sensor Type A has a reliability of 0.9985. 


2 The utopia point represents the ideal architecture which is 100 percent reliable with weight = 0. 
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Therefore, a one-Sensor two-Computer or one-Sensor three-Computer architecture that contains 
Sensor A can have a maximum reliability of 0.9985. Architectures that have a single point 
failure at Sensor A, define the first (least reliable) cluster of data points. Both Sensor Type B 
and Computer Type A have the same reliability of 0.999. Therefore, architectures that have a 
single point failure at a Sensor of Type B, or a single point failure at a Computer of Type A, will 
fall into the second cluster. Similarly, Sensor Type C’s reliability of 0.9995 defines the third 
cluster, Computer Type B’s reliability of 0.9996 defines the fourth cluster, and Computer Type 
C’s reliability of 0.9998 defines the fifth cluster. 

The sixth and final (most reliable) cluster contains all other architectures (i.e., architectures free 
from single point failures). The additional points that do not fall into any of the six clusters are 
single-string architectures (i.e., architectures that contain one Sensor and one Computer). These 
architectures contain not one, but two single point failures and are therefore significantly less 
reliable than an identical architecture with additional Computers or additional Sensors. 
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Figure 7.4-1. Architecture Pareto Plots 

Note: (Top) Pareto plot with added details for number of connections between Sensors and Computers, (Middle) 
zoomed in version of the same plot, (Bottom) potential optimal architectures for this scenario: (From left to right) 
Architecture 1 has weight =12 and reliability = 0.9999967, architecture 2 has weight =15 and reliability = 
0.9999989, architecture 3 has weight =17 and reliability = 0.99999959, and architecture 4 has weight =18 and 
reliability = 0.9999999956 
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Figure 7.4-2. Architecture Pareto Plots 
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Note: (Top) Pareto plot with added details for both number of Sensors and number of Computers, (Middle) zoomed 
in version of the same plot, (Bottom) potential optimal architectures for this scenario: (From left to right) 
Architecture 1 has weight =12 and reliability = 0.99999675437371, architecture 2 has weight =15 and reliability = 
0.999998997632005, and architecture 3 has weight =18 and reliability = 0.999999995634079 


NESC Request No.:06-074-I 


# 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

06-074 

Version: 

1.0 

Title: 

System Architectural Considerations on Reliable 
Guidance, Navigation, and Control (GN&C) for 
Constellation Program (CxP) Spacecraft 

Page #: 

31 of 88 


3x2 system, connection reliability = 0.99995, connection weight = 0.5, no penalty 



Utopia Point 


3x2 system, connection reliability - 0.999S5. connection weight = 0.5, no penalty 


24 - 


— r 


— i 1 1 

1 1 

1 — 

JO, dll ^UX'-ilA-t-i k) 

cj'A 

- 



A 

* 

At * £3 E) * 



o 

Computer Type A 

A 

o * Odt OQA 

QA 0><D A 


o 

Computer Type S 

□ 

□ * 

□ *>4&o m a a a 

□ A 


o 

Computer Type C 


■0* -OdD a D DfeA ADA 

, 

□ 

Computer Types AA 

O m 

a te a .-pi 

on □ A □ OA 


□ 

Computer Types AB 


i UJS* nn 

□ □ 

OA 


□ 

Computer Types AC 

* 

at 

a* oa 

□ 0 

OA 


o 

Computer Types BB 

□ ft 

flO 

0 0 A 

□ 0 

A 


o 

Computer Types BC 


A A 

n jA rpfi n A 




o 

Computer Types CC 

° 

o w 

U 4* LlU LI 44 

D 



A 

Computer Types AAA 


□ Q 

□ tA □ 


° ^“Archite 


& 

Computer Types AAB 

a qa 

A 

A m 

□ 

°\ 


A 

Computer Types AAC 

A C 

1 CA 

□ □ o 

□ 

Architecture 

■ 

* 

Computer Types ABB 

a □ 


OA 

□ 



* 

Computer Types ABC 


O 

A 

□ 



* 

Computer Types ACC 

A 


US A 

\ 



* 

Computer Types BBB 

Q A □ 


□ 

\ 


- 

* 

Computer Types BBC 



□ 

Architecture 2 - 


* 

Computer Types BOC 

□ 

O 





■? 

Computer Types OCC 

1 





- 



□ 

□ 

^ Architecture 1 

- 

! 


□ 

t ! 1 

1 


1 

i 

ZTN , 


ture 4 


0,999992 0.9SSS93 0.999994 0.999995 0.999996 0 999997 0.99999B 0999999 

Reliability 


to 1,000001 

Utopia Point 


Figure 7.4-3. Architecture Pareto Plots 
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Note: (Top) Pareto Plot with Added Details for Both Number and Types of Computers, (Middle) Zoomed in version 
of the same plot, (Bottom) potential optimal architectures for this scenario: (From left to right) Architecture 1 has 
weight = 14 and reliability = 0.999996754062388, architecture 2 has weight = 17 and reliability = 
0.999998992620742, architecture 3 has weight = 19 and reliability = 0.999999593334442, and architecture 4 has 
weight = 19.5 and reliability = 0.999999983481890 
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Note: (Top) Pareto plot with added details for both number and Types of Sensors, (Middle) zoomed in version of 
the same plot, (Bottom) Potential optimal architectures for this scenario: (From left to right) Architecture 1 has 
weight = 15.333 and reliability = 0.999993257523472, architecture 2 has weight =17 and reliability = 
0.99999501059889, architecture 3 has weight = 18.667 and reliability = 0.999996753726173, architecture 4 has 
weight = 20 and reliability = 0.999997398039817, architecture 5 has weight = 21.667 and reliability = 
0.999998992071849, and architecture 6 has weight = 23 and reliability = 0.999999983481890 
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The ideal case would be that there is no penalty for connection weight or using dissimilar 
components, which can be seen in Figure 7.4-1. In this scenario, all identified architectures are 
fully cross-strapped. This is to be expected since additional connections increase reliability yet 
cost nothing. Figure 7.4-1 also demonstrates that the weight of an architecture’s component 
plays a major role in determining the optimality of the architecture. Recall that components of 
Type A are the lightest and least reliable, and that components of Type C are the heaviest and 
most reliable. Even though components of Type A is the least reliable, Sensors of Type A and 
Computers of Type A are by far the most prevalent component Types in all the optimal 
architectures. In addition, although components of Type C are the most reliable, no components 
of this type appear in any of the optimal architectures. Furthermore, there were no Sensors of 
Type B in the optimal architectures. Architecture three contains a Computer of Type B, but this 
architecture is no longer optimal once the “dissimilar components penalty” is increased from 
penalty = 0 to penalty = 6 (see Figure 7.4-2). Since the optimal architectures for penalty = 6 
contain no dissimilar components, increasing the penalty to = 9 results in no further changes to 
the optimal architectures. 

Figure 7.4-3 provides a baseline for what can be considered a realistic system. In this scenario, 
there are no longer perfect connection reliabilities of 100 percent and there is a cost for 
producing connections (i.e., connection reliability = 0.99995 and connection weight = 0.5). As a 
result of the 0.5 connection weight, only one fully cross-strapped architecture (Architecture 1) is 
among the optimal architectures. The other optimal architectures have 3 or 4 connections. 
Among these, Architectures 2 and 3 are the most interesting. Each has three Sensors and two 
Computers with two of the Sensors having one connection to a Computer and the last having two 
connections. 

The scenario in which connection weight = 0.5 is similar with the connection weight = 0 
scenario. Once again, the component types in the optimal architectures are predominantly of 
Type A and never of Type C. Only one optimal architecture (Architecture 3) contains a 
component of Type B (Computer). This architecture is not optimal when the dissimilar 
components penalty is increased to penalty = 6. There is no change in optimal architectures for 
connection weight = 0.5 when this penalty is increased from penalty = 6 to = 9. 

Figure 7.4-4 depicts the first scenario where connection reliability = 0.9999 and connection 
weight = 5/3. This scenario produces similar optimal architectures to the connection weight = 

0.5 scenario, but with notable exceptions. 

Even with the dissimilar components penalty set to penalty = 0, connection weight = 5/3 is 
sufficiently high as to eliminate any architecture that contains a component type heavier than 
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Type A. This means that Architecture 3 from Figure 7.4-3 is the only connection weight = 0.5 
architecture which contains a component of Type B, and is not an optimal architecture for 
connection weight = 5/3. This also means that the optimal architectures for connection weight = 
5/3 will not change if the dissimilar components penalty is increased to penalty = 6 or = 9. 

A connection weight of 5/3 makes it more desirable to have architectures with fewer 
connections. Although Architectures 1, 2, and 4 from Figure 7.4-3 are still optimal architectures 
when the connection weight is increased to 5/3, the value of these architectures was diminished 
with the heavier connection weight. As a result, these architectures are no longer closer to the 
utopia point than Architectures 1, 2, and 4 from Figure 7.4-4. 

The six potentially optimal architectures for connection weight = 5/3 produce an interesting set. 
All legal architectures with four or fewer connections that contain two to three Sensors of Type 
A and two Computers of Type A are optimal architectures for this scenario. In effect, a system 
architect is directly trading an increase in weight for additional reliability when connection 
weight = 5/3. 

By reviewing a subset of the possible architectures, specifically a subset in which all members 
have the same number of connections, the effect of the dissimilar components penalty on the 
optimal architectures is nearly identical to the penalty’s effect on the optimal architectures of the 
superset. Figures 7.4-5 and 7.4-6 depict the optimal architectures for 3 x 2 systems with 
1 through 9 connections when the connection reliability equals one and connection weight equals 
zero. The reliabilities and weights for these architectures can be found in Tables 7.4-1 and 7.4-2. 
Again, as the penalty is increased from penalty = 0 to 6, nearly all architectures containing 
Sensor Type B or Computer Type B cease to be optimal. For architectures with the same 
number of connections, the same architectures which are optimal for penalty = 0 will be optimal 
no matter what the connection weight. Similarly, architectures which are optimal for penalty = 6 
or9 remained optimal no matter what the connection weight. Although the overall system weight 
of any subset member will change if the connection weight is modified, this change will be 
identical to the transformation seen by any of the other systems in this subset. This is because all 
systems in each subset have, by definition, the same number of connections. Therefore, among 
architectures with the same number of connections, the architectures closest to the utopia point 
will remain closest to the utopia point regardless of the change to the connection weight. 
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Table 7.4-1. Reliabilities and Weights for the 1- through 9- Connection Architectures Closest the 

Utopia Point 

Note: Assuming a 3 X 2 System with Connection Reliability = 1, Connection Weight = 0, and No Penalty for 
Dissimilar Components 


Connections 

Reliability 

Weight 

On Pareto front? 

1 0.99 

9100405 

14 


0.99 

9300245 

19 


2 0.99 

9993766 

12 


0.99 

9995260 

14 


0.99 

9996397 

16 


0.99 

9997344 

19 


0.99 

9997754 

20 


0.99 

9998292 

22 


0.99 

9998741 

25 


3 0.99 

9995260 

12 


0.99 

9996756 

14 


0.99 

9997499 

15 


0.99 

9998996 

17 


0.99 

9999984 

18 


4 0.99 

9996754 

12 

Yes 

0.99 

9998993 

15 


0.99 

9999594 

17 


0.99 

9999988 

18 


5 0.99 

9998995 

15 


0.99 

9999596 

17 


0.99 

9999992 

18 


6 0.99 

9998998 

15 

Yes 

0.99 

9999597 

17 

Yes 

0.99 

9999996 

18 


7 0.99 

9999994 

18 


8 0.99 

9999996 

18 


9 0.99 

9999996 

18 

Yes 


NESC Request No. :06-074-I 


% 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

06-074 

Version: 

1.0 

Title: 

System Architectural Considerations on Reliable 
Guidance, Navigation, and Control (GN&C) for 
Constellation Program (CxP) Spacecraft 

Page #: 

36 of 88 



Figure 7.4-5. Architectures Described in Table 7.4-1 
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Table 7.4-2. Reliabilities and Weights for the 1- through 9- Connection Architectures Closest the 

Utopia Point 

Note: Assuming a 3 X 2 System with Connection Reliability = 1, Connection Weight = 0, and Penalty = 6 for 
Dissimilar Co mponents 


Connections Relia 

bility 

Weight 

On Pareto front? 

1 0 

.999100405 

14 


0 

.999300245 

19 


20 

.999993766 

12 


0 

.999996397 

16 


30 

.999995260 

12 


0 

.999997499 

15 


0 

.999999984 

18 


40 

.999996754 

12 

Yes 

0 

.999998993 

15 


0 

.999999988 

18 


50 

.999998995 

15 


0 

.999999992 

18 


60 

.999998998 

15 

Yes 

0 

.999999996 

18 


70 

.999999994 

18 


80 

.999999996 

18 


90 

.999999996 

18 

Yes 
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Figure 7.4-6. Architectures Described in Table 7.4-2 
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7.5 Concluding Remarks 

There is merit in mapping the entire possible solution space. By showing where similar classes 
of solutions fall within the entire set, it allows one to see ‘and how certain solution features effect 
FOM performance and derive architecture ‘rules of thumb’. It also allows one to see the optimal 
solution boundary (the Pareto Front) and understand how one FOM can be exchanged for 
another. 

This approach provides insight into a potential limitation of the ‘Minimum 
Functionality/Minimum Implementation’ system architecting methodology [ref.6] which uses as 
its starting point a single-string non-redundant system architecture which lies somewhere in the 
interior of the solution trade space. The method involves performing one trade at a time to 
improve system safety until the mass margin is gone. It is not clear that this stepwise 
optimization of a single design can ever get to the boundary of optimal solutions (the Pareto 
Front). Even if it somehow did reach the optimal boundary it is not clear the system architects 
will have access to and be able to visualize the whole range of optimal solutions. System 
architects using the ‘Minimum Functionality/Minimum Implementation’ approach should at least 
be aware that the technique described in this report is available and they should consider using it 
to explore the entire system trade space and to provide some comparative outputs for cross-check 
their results. 

With some enhancements the systematic GN&C/ Avionics “building block” OPN modeling 
techniques employed by the MIT/Draper Laboratory would serve as an excellent tool for 
evaluating competing GN&C system architectures for future NASA spacecraft. This OPN-based 
approach, or other similar modeling tools, would perform the extremely useful up-front function 
of identifying the most attractive (lowest weight and overall “cost”) GN&C architectural options 
that satisfy a prescribed set of spacecraft fault tolerance, reliability and performance 
requirements. Although less likely, but worth observing, is the fact that such “building block” 
models could be used to identify the optimal highest reliability/lowest weight architectural 
options for a prescribed number and configuration of connections between adjacent GN&C 
components. 

On-board GN&C flight software was, by design, not included in this GN&C system modeling 
and analysis study. Since there are potential for achieving flight software commonalty across 
multiple spacecraft this aspect of the system architecture should be considered in future work. 
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8.0 Findings and NESC Recommendations 

8.1 Findings 

The following NESC/MIT/Draper Laboratory study team findings were identified: 

F-l. Most optimal architectures can be created by using the lowest reliability and lightest 
components. 

• The analysis of the identified optimal architectures show that it is possible to produce 
nearly all potentially optimal architectures using only the Type A light weight/low- 
reliability Sensors, Type A light weight/low-reliability computers, and generic 
connections. 

F-2. It is preferable to increase the redundancy of lighter, less reliable components rather than 
to use smaller numbers of more reliable, heavy components. 

F-3. There are diminishing returns to adding redundancy, connections, or components with 
greater reliability. 

• The system will experience only minimal increases in overall reliability for the large 
gains in system weight. 

F-4. For the optimal architectures in each scenario, the number of connections drops 
dramatically as the connection weight penalty is increased. 

F-5. The impact of the dissimilar components penalty is more subtle than that for connectors, 
but is still apparent. 

• Some architectures containing both Computer Type A and Computer Type B were 
identified as potentially optimal when the penalty = 0. However, when the penalty is 
increased to = 6, these architectures no longer appear to be better than other 
architectures. 

F-6. The OPN-based modeling approach employed required a time-consuming manual 
process for eliminating architectural duplicates. 

F-7. The OPN-based modeling approach employed was top-level only. 

F-8. In addition to the reliability metric, the existing OPN model could be modified to 

identify the optimal GN&C /Avionics architectural options for satisfying other driving 
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system metrics, such as fault tolerance constraints, avionics power consumption, and/or 
attitude control performance. 

8.2 NESC Recommendations 

The following NESC recommendations were identified and directed to the ESMD 

Chief Engineer, the CxP Program System Engineering organization, and the Orion and Altair 

GN&C/ Avionics Subsystem designers: 

R-l. Consider the fundamental findings of the NESC/MIT/Draper Laboratory study team to 
determine, given their reliability modeling assumptions, if the trends identified can be 
applied to architecting future CxP spacecraft GN&C/ Avionics subsystems. 

(F-l, F-2, F-3, F-4, and F-5) 


R-2. Com prehensively investigate, using the OPN-based model described in this report (or 
using similar GN&C/ Avionics modeling tools and methods) both the pros and cons of 
incorporating dissimilar GN&C Sensor, Computer, and Actuator components in the 
GN&C architectures. Study how a small set of crew/flight safety critical GN&C 
functions can be synthesized/implemented in a backup ma nn er with a limited 
complement of dissimilar hardware and software components. (F-5) 

R-3. Future work in on reliable GN&C should include the following enhancements of the 
GN&C/Avionics system modeling approach (F-6, F-7, F-8, and F-9): 

a) Improve the efficiency of the OPN model processing and its memory 
management. 

b) Incorporate provisions to model more than three Types of GN&C Sensors, 
Computers, and Actuators into the model. 

c) Include additional intrinsic descriptive details for each component beyond 
reliability and weight. 

d) Support expanded GN&C/Avionics architectural layouts in which the component 
redundancy for any component can be greater than three. For example the 
enhanced model should be capable of evaluating an architecture consisting of four 
Sensors, three Computers, and two Actuators. 

e) Automate the process for eliminating architectural duplicates and for creating 
rules. 

R-4. Future work on reliable GN&C should include the addition of the following metrics for 
higher-fidelity analysis and evaluation of GN&C/Avionics system architectural 
robustness, reliability, mass, power, volume, and performance (F-9): 
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a) The fault tolerance requirements/rules for the specific spacecraft application being 
modeled. Metrics on the cost of any analytical redundancy (i.e., the redundancy 
management software) needed to detect and isolate faults should be provided for 
evaluation. 

b) The impact of common mode hardware failures. The metric could be either the 
incremental benefit of dissimilar redundancy or the incremental risk of similar 
redundancy. 

c) The values for Sensor, Computer, and Actuator component Mass, Volume, and 
Power (MVP). 

d) The 6-DOF spacecraft attitude and position control/knowledge performance 
metrics. 

9.0 Alternat e Viewpoints 

There were no alternate viewpoints or minority opinions expressed by the members of the 

NESC/MIT/Draper Laboratory study team. 

10.0 Other Deliverables 

There are no other deliverables at this time. 

11.0 Lessons Learned 

There were no lessons learned. 


12.0 Definition of Terms 

Corrective Actions Changes to design processes, work instructions, workmanship practices, 
training, inspections, tests, procedures, specifications, drawings, tools, 
equipment, facilities, resources, or material that result in preventing, 
minimizing, or limiting the potential for recurrence of a problem. 


Finding 


A conclusion based on facts established by the investigating authority. 


Lessons Learned Knowledge or understanding gained by experience. The experience may 
be positive, as in a successful test or mission, or negative, as in a mishap 
or failure. A lesson must be significant in that it has real or assumed 
impact on operations; valid in that it is factually and technically correct; 
and applicable in that it identifies a specific design, process, or decision 
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that reduces or limits the potential for failures and mishaps, or reinforces a 
positive result. 

Observation A factor, event, or circumstance identified during the assessment that did 

not contribute to the problem, but if left uncorrected has the potential to 
cause a mishap, injury, or increase the severity should a mishap occur. 
Alternatively, an observation could be a positive acknowledgement of a 
Center/Program/Project/Organization’s operational structure, tools, and/or 
support provided. 

Problem The subject of the independent technical assessment/inspection. 

Proximate Cause The event(s) that occurred, including any condition(s) that existed 

immediately before the undesired outcome, directly resulted in its 
occurrence and, if eliminated or modified, would have prevented the 
undesired outcome. 

Recommendation An action identified by the assessment team to correct a root cause or 

deficiency identified during the investigation. The recommendations may 
be used by the responsible Center/Program/Project/Organization in the 
preparation of a corrective action plan. 

Root Cause One of multiple factors (events, conditions, or organizational factors) that 

contributed to or created the proximate cause and subsequent undesired 
outcome and, if eliminated or modified, would have prevented the 
undesired outcome. Typically, multiple root causes contribute to an 
undesired outcome. 

13.0 Acronyms List 

CaLV Cargo Launch Vehicle 

CE&R Concept Exploration and Refinement 

CEV Crew Exploration Vehicle 

CLV Crew Launch Vehicle 

Cx Constellation 

CxP Constellation Program 

DOF Degree of Freedom 

EDS Earth Departure Stage 

ESMD Exploration Systems Mission Directorate 
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F OM F igure of Merit 

IMU Inertial Measurement Unit 

JSC Johnson Space Center 

LaRC Langley Research Center 

LSAM Lunar Surface Access Module 

MTBF Mean Time Between Failure 

MVP Mass, Volume and Power 

NESC NASA Engineering and Safety Center 

NRB NESC Review Board 

TDT Technical Disciple Team 

TIM Technical Interchange Meeting 
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Volume II: Appendices 
Appendix A. 

Appendix B. 

Appendix C. 


A Comparison of GN&C Architectural Approaches for Robotic and 
Human-Rated Spacecraft (A copy of this report is available through AIAA) 

A Comparison of Fault-Tolerant GN&C System Architectures Using the Object 
Process Network (OPN) Modeling Language 

NESC Stakeholder Outbrief 
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Appendix A. A Comparison of GN&C Architectural Approaches for 
Robotic and Human-Rated Spacecraft 
(A copy of this report is available through AIAA) 


AIAA Gutdanoe, WiHgJtion and Cortird Cftilstwct and Exhibit, 2d -23 Aug ZOO?, Rlfon Head, SC 

A Comparison of GN&C Architectural Approaches for 
Robotic and Human-Rated Spacecraft 


Alejandro D. Domingueas-Garcfa*, Gregor Z. Hanuschak*, 
Steven R. Hall* and Edward F. Crawley^ 

Massachusetts Irish lute of Technology, Cambridge t MA r 02139, USA 
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Appendix B. A Comparison of Fault-Tolerant GN&C System 
Architectures Using the Object Process Network (OPN) Modeling 

Language 

A Comparison of Fault-Tolerant GN&C System 
Architectures Using the Object Process Network (OPN) 

Modeling Language 


Gregor Z. Hanuschak 1 

Massachusetts Institute of Technology, Cambridge, MA 02139 
Nicholas A. Harrison 2 

Charles Stark Draper Laboratory, Cambridge, MA 02139-4307 

Edward F. Crawley 3 and Steven R. Hall 4 
Massachusetts Institute of Technology, Cambridge, MA 02139 

Alejandro D. Dominguez-Garcia 5 
University of Illinois at Urbana-Champaign, Urbana, IL 61801 

John J. West 6 

Charles Stark Draper Laboratory, Cambridge, MA 02139-4307 
and 

Cornelius J. Dennehy 7 

NASA Engineering & Safety Center, Greenbelt, MD, 20771 


This paper summarizes the final results of a study analyzing different Guidance, 
Navigation and Control (GN&C) architectural approaches for fault tolerance in National 
Aeronautics and Space Administration’s (NASA’s) crewed and robotic exploration space 
systems. GN&C systems were decomposed into simple building block subunits of sensors, 
computers, and actuators and various forms of subunit interconnection were defined for 
investigation. The resulting subunit/interconnection construct was used as a top-level 
abstraction for building candidate GN&C system architectures. This model was 
implemented using Massachusetts Institute of Technology’s (MIT’s) Object Process Network 
(OPN) modeling language in order to more easily enumerate possible architectures and 
ultimately identify which of these architectures have optimal properties. Dual and triple 
redundant GN&C system architectures, employing different classes of components, were 
modeled using the OPN language. The model assumed perfect coverage - 100-percent 
accuracy in detecting and isolating a failure. Within the constraints of the model, all possible 
architectures were rigorously enumerated and the weight/reliability trade-offs of cross- 
strapping components and using more than one type of component were assessed. The study 
results indicate it is possible to produce nearly all potentially optimal GN&C architectures 
using generic connections between low-reliability components. The identified optimal 
architectures reveal a preference to increase GN&C system redundancy of lighter, less 
reliable components rather than using smaller numbers of more reliable, heavy components. 
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Nomenclature 


CEV 

- Crew Exploration Vehicle 

CLV 

= Grew Launch Vehicle 

CxP 

- Constellation Program 

GN&C 

- Guidance. Navigation and Control 

1MU 

= Inertial Measurement Unit 

mr 

— Massachusetts Institute of Technology 

NASA 

= National Aeronautics and Space 
Administration 

NESC 

= NASA Engineering and Safety Center 

OPN 

~~ Object Process Network 


I. Background 

A T the core of NASA’s future space exploration is a return to the Moon, where we will build a sustainable long- 
term human presence As the Space Shuttle approaches retirement and the International Space Station nears 
completion, NASA's Constellation Program (CxP) is designing and developing the next fleet of American space- 
faring vehicles to bring astronauts back to the Moon, and possibly to Mars and beyond, in order to meet, their 
exploration goals, NASA's CxP will have to acquire and operate a number of new hum an -rated systems, such as the 
Orion Crew Exploration Vehicle (CEV), the Arcs-1 Crew Launch Vehicle (CLV), and the Altair Lunar Lander, 
along with other elements Tor crew transportation (eg., in-space propulsion stages), lunar habitation, and mobility. 
Robotic systems will include lunar robotic or biter vehicles and robotic lunar landers. Commonality in exploration 
system hardware, and software elements offers the opportunity to significantly increase sustainability by reducing, 
both nonrecurring and recurring cost and-or risk. In particular the potential bench l of common GN&C avionics and 
flight software is considerable, not only in the initial development effort, but in validation and verification, and more 
importantly in the ongoing maintenance efforts and incremental upgrades that will occur over (he life cycle of these 
exploration spacecraft With commonality of the onboard components of this system, there is more likelihood that 
ground control and communications systems could be made more common, yielding a multiplier effect This paper 
summarises the final results of a comparative assessment of robotic and human-rated GN&C system architectural 
approaches. This study was performed by a combined MIT and Draper Laboratory team as pan of a proactive 
GN&C “discipline-advancing'’ activity sponsored by the NASA Engineering and Safety Center (NESC), 

This study effort was primarily driven by the observation, both on the part of NESC and MIT, that GN&G 
systems for exploration prominently stand out among all the future spacecraft systems, as an area where 
commonality might be of greatest benefit. This comparative assessment of robotic and human-rated GN&C system 
architectural approaches was undertaken as a fundamental step towards understanding the opportunities and 
limitations of GN&C commonality across the CxP flight elements. 


II. Introduction 

CxP has created a need to develop new robotic and human-rated space systems In an attempt to influence the design 
of the most collectively reliable and cost-efficient systems possible, the NESC sponsored a commonality study for 
GN&C systems through the MIT and Draper Laboratories. By modeling, enumerating, and comparing simplified 
GN&C architectures using simple metrics, this resulting paper presents sound reasoning for making certain 
architectural choices which, when implemented, would further these reliability and cost-efficiency goals 

In Lhe 2007 AlAA paper, “A Comparison of GN&C Architectural Approaches for Robotic and Human-Rated 
Spacecraft” (Ref. 2), different architectural approaches for fault tolerance in guidance, navigation, and control 
(GN&C) systems were analyzed at the topmast level. The study broke down the GN&C systems into simple 
subunits, i.e., sensors, computers, and actuators, and analyzed how the components were interconnected. This paper 
expands upon the previous 2007 paper written by the authors. Tt uses Lhe previous paper's subuni t/interconnection 
construct as a top-level abstraction for building a preliminary model of GN&C system architectures. 
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Although never before used to model GN&C system architectures, the OFN modeling, language was used with 
great success to model mission and hardware architectures (see Ref. 3 and Re!’. 5 for details). OPN is a visual and 
computable meta-language that assists with systems architecting tasks. OPN is typically used to describe and 
partition the space of architectural alternatives, generate and enumerate the set of instances of feasible system 
models, and then simulate and order the performance metrics of each model, This language combines visual 
representation on Pareto plots with mathematical modeling and provides a modeling framework in which it is 
relatively easy to add new options to understand the effect of new technologies and different configurations. 
Moreover, as proven in this study, the OPN language is applicable to many 14 levels" of a given architecture 

Candidate GN&C system architecture models were implemented using the OPN modeling language in order to 
more easily enumerate possible architectures and ultimately identify which architectures have optimal properties. 
Following the basic procedure employed in the above references and using Ref. 2 to provide the background for the 
top-level abstraction used in the model, OPN was successfully employed in the models described in this paper 

Partial 2 x 2 systems (i.e., systems with up to dual redundancy per component class for two component classes) 
and 3 X 2 systems (systems with up to triple redundancy per component class for two component classes) were 
modeled in OPN. Within the constraints of these models, all possible architectures were rigorously enumerated and 
the weight/rd lability trade-offs of cross-strapping components and using more than one type of component were 
assessed. 

The described models assume perfect coverage - 100-percent accuracy in detecting and isolating a failure. The 
models also assume that more reliable components lend to be heavier, more costly, and/or more complicated to deal 
with. Given these assumptions, it w r as found that more reliable components are only beneficial in single string 
systems or systems with single point failures. All optimal architectures employing component redundancy could be 
produced from generic connections and the least reliable type of component from each component class. 

According to Ref 2, a GN&C system can be represented with sensors, computers, actuators, and how r these 
components are interconnected. Given this abstraction, the completed OPN model discussed in this paper represents 
ail possible GN&C architectures within a given set of constraints. The constraints are defined as the number of 
component classes^ the maximum component redundancy in each component class, and the number of component 
types for each class 

In this paper, sensors, computers, and actuators will he defined as “component classes,” The terminology T x J 
OPN modeF will be used to describe a model with up to T' redundancy per component class and up to “F 
component classes. In other words, J - 2 could designate a model which only has sensors or which has both sensors 
and computers. J 3 could designate a model with sensors, with sensors and computers, or with sensors, computers, 
and actuators. If J = 3 and 1 = 2, this could designate a system with up to two sensors, two computers, and two 
actuators. This paper will discuss OPN 2x2 and 3x2 models and touch on their applicability to a 3 X 3 model. 

For the purpose of simplicity, it will be assumed thaL there are only three different types of components possible 
for each component, class. In reality, three sensor types might include a sun sensor, star tracker, and an inertial 
measurement unit (1MU), However, to be more generic, types will not be designated so specifically - they will 
instead be referred to as type A, type B, and type C 

As a first pass, all enumerated architectures are evaluated based on two specific metrics: reliability and weight. 
Note that, with some exceptions, both complexity and cost increase as weight increases: thus, weight is a good first 
order approximation for these metrics. 

Section III of this paper will discuss the design of the simple 2 x 2 model, section IV will give further details on 
the model, and Section V will discuss the design of the more complicated 3x2 model. Section VI will examine the 
application of reliability and weight metrics to the enumerated architectures. Finally, Section VU concludes and 
describes the model's future iterations. 


IIL A “2 x 2” GN&C System 

This section begins the discussion of the design of the 2 x 2 model. Even with just four components (two sensors 
and Lw r o computers), many architectures can be defined for a 2 X 2 system based on how the components are 
interconnected. Each of these architectures will have different total weight and different total reliability. 
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Figure 1 Three possible 2x2 systems. 

Figure 1 depicts three possible 2x2 architectures. The reliability R of the three models is shown in Table 1 
where Sj is the reliability of sensor j and c k is the reliability of computer k. 


Table L Reliability expressions for the 2x2 systems in Figure 1. 


Architecture 

Reliability 

Channelized 

R $|Ci 4" SjCj — 

Hybrid 

R ” S1C1 + SiCi + S 2 C 2 S2C1C2 SiSjsCi S1S2C1C2 4 

S,SjCiC 2 

Cross- Strapped 

R = Sj Cj ^ Sjpj — " 1 * K 2 C| 4 * S 2 C 2 — Sr 2 C|C 2 — SiS 2 Cj 

2S1S2C1C2 + 2 SXS 2 C 1 C 2 S1S2C2 4“ 2S1S2C1C2 SiSiCjCj 


It is important to note that, no matter what the architecture, the reliability of any 2x2 model can be generated by 
taking the cross-strapped expression for R and then eliminating terms from the expression for connections which do 
not exist and therefore do not contribute to system reliability. 

Additional indicator variables are added to the cross-strapped reliability expression to specify which terms to 
eliminate These indicator variables are coTTclalcd with the interconnections between components. A nonzero 
indicator variable represents a connection whereas an indicator variable equal to zero represents a missing 
connection. 

Using the methodology described, the following general expression for R is obtained: 

R - SiinCj + SiiijC2 - SiiniiaCiCi + Szi2i c i + - SiSahiteiPi - SiSaiui^QiCa - s 1 s 2 i 12 i 21 c 1 c 2 + 

SiSiiidiahiCiCi + S1S2I11I21I22C1C2 SiS^iniiiCi + SiSaiuiuiaaCiPa + SiSaiiaizihaCiCi SiSjinii^iijaCxC^ 
where is the reliability of the connection between sensor j and computer k if such a connection exists and is 0 
otherwise 

As a sanity check, Lhe reliability expressions for the channelized and hybrid architectures above can be derived 
from the general expression. Assuming perfect connection reliability, i.c , i jl( - 1 for all connections in the 
architecture, the channelized and hybrid architectures would he represented by the indicator variables in Table 2. 
Plugging these indicator variables into the general expression gives the same reliability- expressions in Table 1. 


Table 2. Indicator fur the channelized and hybrid 2x2 systems in Figure 1. 


Architecture 

in 

in 

i?i 

i zl 

Channelized 

1 

0 

0 

1 

Hybrid 

1 

0 

1 

1 


IV. Details on the Model 

This section gives further detail on the 2 x 2 model. Like the previously mentioned 3x2 and 3x3 models, the 2 
X 2 OPN model can be viewed as a sophisticated Petri net model. In a Petri net model, inform ation-storing tokens 
move via directed arcs from transitions to places and from places to transitions. Note that there may be more than 
one directed arc feeding from or to a transition or place. Upon arrival at a transition, a token is consumed, some 
processing is done, and, if appropriate, new tokens are introduced in the places dictated by the directed arcs leading 
from the transition. 

lhe sequence of transitions in any of the discussed QPN models is a sequence of decision points. At each 
decision point, a token is replicated with multiplicity equal to the number of possible decisions The information 
stored in each token represents a unique possible architecture. Taken together, the tokens enumerate all possible 
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architectures given an initial set of constraints. All tokens are collected when Ihey completely propagate through the 
model for analysis. 

Figure 2 is a visual representation of the OPN decision tree for the 2x2 model and tire following questions are 
the decision points: 

* How many sensors? 

o 1 or 2 

* Type assignment for sensors? 

o If only one sensor, choose SensorA, SensorB, or SensorC 

o If two sensors, choose two of the same type of sensor or one of each of two types (possible 
combinations: AA, AB S AC, BI3, BC, and CC) 

• HOW many computers? 

o 1 or 2 

• Type assignment for computers? 

o If only one computer, choose Computer A, ComputcrR, or OomputerC 

o If two com puters, choose two of the same type of computer or one of each of two ty pes (possible 
combinations: AA T AE, AC* RR, RC, and CC) 

* Which sensors arc connected to computer 1? 

o Just sensor 1 

o Just sensor 2 (if sensor 2 exists) 
o Both sensor 1 and 2 (if sensor 2 exists) 

• If computer 2 exists, which sensors are connected to computer 2? 

o Just sensor I 

o Just sensor 2 (if sensor 2 exists) 
o Roth sensor 1 and 2 (i f sensor 2 exists) 
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Figure 2. The 2 it 2 OPN decision tree. 

During the process of token propagation, the number of components, component types, and connections are 
continuously updated for later use in reliability calculations Tn addition, the current weight of the system is updated 
at execution time. 

Each component type is given its own unique reliability and weight based on the specific make and model of the 
component These values were based on real components, but modified slightly to facilitate analysis. 

Reliabilities are dependent upon the failure rate of the component and the desired operational time for the 
component The relationship is governed by the equation R - c '**, where X is the failure rale and l is the operational 
time. Operational time is user defined and based on the length of the proposed mission. An operational time of t - 
10 years was used in ihe models discussed in this paper. Other component properties are illustrated in Table .1 and 
Table 4. 
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Tahle 3. Component properties for sensor types A, B, and C. 


Sensor Type 

A 

B 

C 

Failure Rate X f/year) 

0.00015 

0.0001 

0.00005 

Reliability R 

0.9985 

0.999 

0.9995 

Weight (dimensionless) 

3 

6 

9 


Table 4, Component properties for computer types A, B, and C. 


Compute i 1 Type 

A 

B 

C 

Failure Rate & (/year) 

0.0001 

0.00004 

0.00002 

Reliability R 

0999 

0.9996 

0.9998 

Weight (dimensionless) 

3 

5 

10 


Two additional weights and one additional reliability were also included in the model, A “connection weight" 
and a “dissimilar component penalty" 7 were included to ensure that weight continues to approximate complexity and 
cost. Cross-strapping components may noL add much physical weight to the overall system, but it surely adds to the 
complexity' and cost of the system Similarly, dealing with more than one type of sensor and/or computer also 
increases complexity and cost. Hence, adding these additional weights where appropriate worked as a first step 
toward reality . 

The weights associated with connections and dissimilar components were chosen to be consistent with the 
weights of sensors and computers. To do so, assumptions had to be made. Connections were considered to be, at 
most, one-third of the complexity of the average computer. In addition, the weight penally for dissimilar components 
was set such that it w as not larger than the heaviest sensor or the heaviest computer. 

These logical assumptions dictated a certain range of weight values used for connections and dissimilar 
component parameters However, rather than presuppose exact values for these weights, multiple OFN runs were 
executed varying one of the parameters each time. Assuming the connection reliability would be greater than that of 
a computer, the nine OFN scenarios are illustrated in Table 5. 

Table 5. Connection reliabilities, connection weights, and dissimilar component penalties Tor each OFN 
scenario run. 


OPN Scenario 

1 

2 

3 

4 

5 

6 

7 

8 

9 

Connection 

Reliability 

1 

1 

1 

0.99995 

099995 

0.99995 

0.9999 

09999 

09999 

Connection 

Weight 

(dim ensionless) 

0 

0 

0 

0,5 

0,5 

0.5 

5/3 

5/3 

5/3 

Dissimilar 

Component 

Penalty 

(dim ensio riles s) 

0 

6 

9 

0 

6 

9 

0 

6 

9 


V, A “3 x 2" GN &C System 

This section discusses the design of the 3x2 model. Implementation of the 3x2 OFN model is very similar to 
that of the 2 x 2 model w ith two notable exceptions. These exceptions relate to the reliability formula for the overall 
system and the removal of duplicate architectures to conserve memory. 

The reliability formula is much more complicated for these larger models and must be handled differently. 
Although reliability is still calculated after OFN completes execution, it can no longer be easily calculated by hand 
for implementation in ExceL Instead, symbolic MAT LAB was used to multiply out the formula and a MATLAB 
script was used to insert the correct “T indicator values where appropriate. Only after this manipulation was 
performed could the reliability be imported back into Excel for implementation. 

In addition, care had to be taken to ensure no architecture was represented more than once in the model. Running 
a larger 3x2 OFN model would take an inordinate amount of time and computer memory. It was found that certain 
architectures could be represented in multiple configurations and this was not taken into account by the 2 X 2 


NESC Request No. :06-074-I 


# 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

06-074 

Version: 

1.0 

Title: 

System Architectural Considerations on Reliable 
Guidance, Navigation, and Control (GN&C) for 
Constellation Program (CxP) Spacecraft 

Page #: 

54 of 88 


model® By producing tokens for all possible configurations of the same architecture, the model took much more 
time and used much more memory than necessary. 

An example duplicate architecture is shown in Figure 3. A 1 and A2 represent the same architecture since, in both 
cases, one sensor of type A is connected to a computer of type A, the other sensor A is connected to a computer A 
and a computer B, and a sensor of type B is connected to a computer of type C. A3 represents a different 
architecture, however, since both sensors of type A are connected to a computer of type B 


A1 


A 

| SDnxjf 1 -p\ Oomputor 1 1 

A 

A 

| RansorJ y 

■ Computer ? | 

s 

B 

1 3 , 


c 


A 2 


A 

| Sensor 1 J^- -p\ Compulof 1 j 

A 

A 

| Sfinsor 7 r 


R 

B 


i Computer S| 

C 


A3 


!= 


A 

] Sonsof 1 Jv Computor 1 1 

A 

Senn^S h*- >1 Corner? | 



E 



A 

R 

C 


Figure 3. Detenu illation ot duplicate architectures. 


The process of eliminating duplicate architectures began by choosing a representative set of sensor types and 
computer types, fen possibilities were chosen as representative orderings of the three sensor types and also the three 
computer types: AAA, AAB, AAC, ABB, ACC, ABC, RRB, BBC, BCC, and CCC 

A1 in Figure 3 represents a connection pattern between thr ee adjacent components this connection pattern has 
four connections; Sensor 1 is connected to computer \ t sensor 2 is connected to both computer 1 and computer 
and sensor 3 is connected to computer 3. Keeping this connection pattern fixed, wc can give a 4 Type” identity to the 
three sensors based on the ten possible orderings. For each possible ordering of the sensor types, there are ten 
possible orderings of the computer types, each of which defines a unique architecture. In other words, for any given 
connection pattern such as Al, there are 10 x 10 = 100 possible architectures The QPN model iterates through all 
possible connection patterns and finds at 11 00 possible architectures for each one 

Note lhat orderings such as ABA and BAA are not taken to be representative orderings. When all possible 
connection patterns are taken into account, these additional orderings will fail to produce any architecture that 
cannot be produced by AAB. This is because ABA, BAA, and AAB are all equivalent - all represent two 
components of type A and one of type B. It docs not matter in what order the letters arc written as long as the case is 
represented 

Luckily, searching for duplicate architectures in OPN does not require checking 100 possible architectures for 
each connection pattern. The 100 possibilities for each connection pattern can be represented by just 16 
representative architectures. As illustrated in Figure 4, the ten sensor type combinations and the ten computer type 
combinations can be further abstracted to just four representative combinations per component. First, AAA, BBB, 
and CCC all represent the case where all three components are of the same type. Next, AAB, AAC, and BBC all 
represent the ease where the first two components are of Ihe same type and the third component is of a different 
type. Furthermore, ABB, ACC, and BCC all represent the case where the second and third components are of the 
same type, but the llrst component is of a different type. Finally, ABC represents the case where all three 
com ponents are of a different type. 


The 2 x 2 model is much smaller than the 3 x 2 model. As a result, there were no memory issues and duplicate architectures could be removed 
in post -processing they did not have to be removed in OPN- 
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Figure 4. Kin ding representative architectures. 


Figure 5 helps demonstrate why these representative architectures work for finding duplicate architectures. To 
use representative architectures to find duplicates is to claim that if architecture A I is equivalent to architecture A2, 
but not A3, then architecture B1 is equivalent to B2 ? but. not B3. This is clearly the case. 
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Figure 5. Using representative architectures to find duplicates. 

As previously discussed, A1 and A2 represent the same architecture even though they have different connection 
patterns It is arbitrary which form of an architecture is chosen as the primary form and which is a duplicate - either 
A1 or A2 could be considered the duplicate 

Implementing duplicate detection into the model turned out to be a very involved process. The project had a 
limited time horizon and the development time necessary for automating the duplicate detection process was 
uncertain ft was therefore decided that a surefire yet brute force method w r ould be used to implement duplicate 
detection. All possible representative architectures were drawn by hand and duplicate architectures were circled. In 
all, over 100 pages of architectures were drawn and compared 
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Figure 6. One pa Re of hand- drawn architectures. 


Based on the circled representative architectures, rules were created and inserted into OPN to keep any tokens 
that, will produce duplicate architectures from propagating.. Note that all rules arc in the form of Boolean expressions 
starling with “not if" instead of “if\ Although all work was double- checked, it is conceivable that an incorrect rule 
was entered due to human error. By using “not if™ instead of “if \ the default is to pass the token. It. is better to retain 
a duplicate architecture rather than exclude a potentially optimal architecture. 

The Boolean rules are inserted into the OPN model on the transitions from: 

• Which sensors are connected to computer 1? 

• If computer 2 exists, w hich sensors are connected to computer 2? 

■ If computer 3 exists, which sensors are connected to computer 3? 


To the places: 

o Just sensor 1 

o J usl sensor 2 (i f sensor 2 exists) 

o Just sensor 3 (if sensor 3 exists) 

o Just sensors I and 2 (if sensor 2 exists) 

o Just sensors 1 and 3 (if sensor 3 exists) 

o Just sensors 2 and 3 (if sensor 3 exists) 

l> Sensors 1, 2, and 3 (if sensor 3 exists) 


1 A 
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Trivial rules govern which sensors are connected to computer 1. If a particular token represents an architecture 
with only 2 sensors, it is not possible to make a connection to a computer from a nonexistent sensor 3. Therefore, in 
the 2-sensor case, no new tokens arc introduced into the places representing, "just sensor 3,” " just sensors 1 and 3T 
“just sensors 2 and 3," Or " L sensors 1, 2, and 3.” Similarly, if a particular token represents an architecture with only 1 
sensor, no new tokens are introduced into the places representing, "just sensor 2” "just sensor 3T "just sensors 1 
and 2T just sensors 1 and 3,” "just sensors 2 and 3/’ or “sensors 1, 2, and 3” 

Rules governing connections to computer 2 and computer 3 are mors complicated. If a token represents an 
architecture with only two computers, it. is known what the final system architecture will be after creating the sensor 
connections to the second computer. If a token represents an architecture with three computers, it is known what the 
final system architecture will be after creating the sensor connections to the third computer Connections that will 
form duplicate (circled) architectures should not be allowed to propagate. Hence rules are put in place to block 
introduction o I" these tokens. 

Figure 7 shows an example rule based on a hand-drawn architecture. This rule detenu mes whether or not a 
connection should be made between sensor 3 and computer 3 Note that, by the time a token reaches the given rule, 
the connections between sensor 1 and computer 2 as well as between sensor 2 and computer 1 have already been 
defined. No connection should be made if the type definitions for the sensors and computers match those 
represented by the circled architectures - such tokens will result in the formation of duplicate architectures. In other 
words, the connection between sensor 3 and computer 3 should not be m ade if sensor Vs type is the same as sensor 
2's type or computer Vs type is the same as computer 2 T s type. 



I {Computer Redundancy < 3 } && 

1 (Sensor_Redundancy < 3) && 

2 ( 

(ill ss 0 && i!2 == 0) | | 

(Sensor_Redundancy > 1 && i21 = s= 0 && i22 s== 0 ) | 

( 

(ill = = 0 il2 > 0 && 121 > 0 && i22 = = 0 && i31 == 

0 && 132 == 0} && 

1 

( Sensor l_Type == Sensor 2_Type) | 

( Comput er l_Ty pe = = Comput er 2 Type } 


Figure 1 . An example rule based on a hand-drawn architecture. 

Eliminating duplicate architectures in the 3x2 modet significantly reduced the number of tokens produced. 
Before duplicates were removed, the OPN produced 51,902 tokens. After duplicates were removed, the model 
produced only 9,795 tokens 
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VI. Results 

Despite eliminating the unnecessary duplicate architectures from the model, attempts to run a 3 x 3 model still 
resulted in a memory shortage. Although it is unfortunate that the larger model could not complete, it is important to 
note that results from the 3 x 2 model can still he applied to the 3 x 3 case 

Taking such a top-level view of a GN&C system, the interaction between adjacent sensor and computer 
components is identical to the interaction between adjacent computer and actuator components. Just like sensors and 
computers, there are different types of actuators, each with a unique set of properties, and a system architect can 
choose different redundancies for each of these types. Furthermore, the connection patterns already found between 
sensors and computers are the same as those between computers and actuators Finally, the metrics of weight and 
reliability can be calculated in exactly the same way. 

The nine scenarios outlined in section TV were run and Pareto plots were produced for each. Representative plots 
for each of the nine scenarios are reproduced in Figures £ - 11, In each scenario, the architectures that 
simultaneously had both lowest weight and highest reliability were identified, These architectures are " on the Pareto 
front." The identified Pareto-front architectures for each scenario are reproduced in figures 8-11 as well. These 
architectures were found by zooming in on the 4 ‘utopia point 7 ’ at the lower right hand comer of the plot. 9 Note that, 
in most cases, there are multiple identified architectures for each scenario since it is somewhat subjective which 
architectures are closer to the utopia point Is an architecture with weight “ 1 7 and reliability “ 0 99999959591 2468 
(six li 9”s) better than an architecture with weight - IS and reliability - 0.999999995634079 (eight “9”s)7 The 
answers to such questions would be made clear in a mission requirements context For a human-rated mission, 
perhaps a reliability of 0.9999999 (seven l "9”s) is required for safety. If this were the case, the architecture with 
weight -IS would clearly be better, since the one w ith weight - 1 7 does not meet the requirement. 

In the zoomed out (top) plot of each of the nine scenarios, there appear to be six dusters of architecture data 
points. Although the clusters appear to be columns of data points, they are not; the architectures in each cluster have 
nearly identical, but not completely identical reliabilities. Looking from left to right the first five clusters - the five 
dusters with the lowest reliability - are driven by single point failures of any of the six component types. For 
example, in an architecture that contains one sensor and two computers or an architecture that contains one sensor 
and three computers, the single sensor present in die architecture must remain reliable in order for the overall system 
to remain reliable. Sensor type A has a reliability of 0.9985. Therefore, a one-sensor two-computer or one-sensor 
three-computer architecture that contains sensor A can have a maximum reliability of 0 9985. Such architectures, 
which have a single point failure at sensor A, define the first (least reliable) cluster of data points Both sensor type 
R and computer type A have the same reliability: 0 . 999 . Therefore, architectures that have a single point failure at a 
sensor of type B or a single point failure at a computer of type A will both fall into the second cluster Similarly, 
sensor type C 7 s reliability of 0.9995 defines the third duster, computer type B 7 s reliability of 0.9996 defines the 
fourth cluster, and computer type C T s reliability of 0.9998 defines the fifth cluster. 

The sixth and final (most reliable) duster contains all other archi lectures - architeclnres free from single point 
failures. The few additional points that do not fall into any of the six clusters are single-string architectures, i c., 
architectures that contain just one sensor and one computer. These architectures contain not one* but two single point 
failures and are therefore significantly less reliable than an identical architecture with additional computers or 
additional sensors. 


3 Tht utepia point represents ihc ideal architecture: which is 100 percent reliable with weight 0 

!*> 
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Figures. (Top) Pareto plot, with added details for number of connections between sensors and computers, 
(Middle) zoomed in version of the same plot, (Bottom) potential optimal architectures for this scenario: 
(From left to right) Architecture 1 has weight = 12 and reliability = 0.99999675437371 (five 9s), architecture 2 
has weight = 15 and reliability = 0.999998997632 01 (Five 9s), architecture 3 has weight =17 and reliability = 
0.99999959691247 (six 9s), and architecture 4 has weight = 18 and reliability = 0.99999999563408 (eight 9s). 
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Figure 9- (Top) Pareto plot with added details for both number of sensors and number of computers, 
(Middle) zoomed in version of the same plot, (Bottom) potential optimal architectures for this scenario: 
(From left to right) Architecture 1 has weight = 12 and. reliability = 0.99999675437371 (five 9s), architecture 2 
has weight = 1 5 and reliability = 0.99999899763201 (five 9s), and architecture 3 has weight = 1 8 and reliability 
= 0. 999999 99563 408 (eight 9s). 
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Figure 10. (Top) Pareto plot with adder! details for both mini her and types of computers, 

(Middle) zoomed in version of the same plot, (Bottom) potential optima] architectures for this scenario: 
(From left to right) Architecture 1 has weight = 14 and reliability = 0. 9 9999 fi 754062 3 88 (five 9s), architecture 
2 has weight - 17 and reliability - 0.999998992620742 (five 9s), architecture 3 has weight - 19 and reliability 
= 0.999999593334442 (six 9s), and architecture 4 has weight = 19.5 and reliability = (1.999999983481 890 (seven 
9s). 
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Figure 1 1 . (Top) Pareto plot with adder! details for both number and types nf sensors, 

(Middle) zoomed in version of the same plot, (Bottom) Potential optimal architectures for this scenario: 
(From left to right) Architecture 1 has weight = 1 5.333 and reliability = 0.999993257523472 (five 9s), 
architecture 2 has weight - 17 and reliability - 0.99999501 05988 9 (five 9s), architecture 3 has weight - 18.667 
and reliability = 0.999996753726173 (five 9s), architecture 4 has weight = 2(1 and reliability = 
0.999997398039817 (five 9s), architecture 5 has weight = 21.667 and reliability = 0.999998992071849 (five 9s), 
and architecture 6 has weight = 23 and rel nihility = 0.999999983481890 (seven 9s). 
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Many interesting aspects can be found in Figure 8, the ideal case where there is no penalty for connection weight 
or using dissimilar components. In this scenario, all identified architectures are fully cross-strapped This is to be 
expected since additional connections increase reliability yet cost nothing. Figure 8 also demonstrates that the 
weights Of an arch i tec hire's component plays a major role in determining the optimality of the architecture. Recall 
that components of type “A” are the lightest and least reliable and that components of type “C" are the heaviest and 
most reliable Even though components of type are the least reliable, sensors of type A and computers of type A 

are by far Ihe most prevalent component types in all the optimal architectures. In addition, although components of 
type “CT are the most reliable, no components of this type appear in any of the optimal architectures. Furthermore, 
there are not even any sensors of type B in ihe optimal architectures. Architecture 3 contains a computer oT type B, 
but this architecture is no longer optimal once the "dissimilar components penalty'" is increased from penalty _ 0 to 
penalty = 6 (see Figure 9. bottom). Since the optimal architectures for penalty - 6 contain no dissimilar components, 
increasing the penalty again to penalty 9 results in.no further changes to the optimal architectures. 

Figure 10 gives a baseline for what is realistic. In this scenario, there are no longer perfect connection 
reliabilities of 100 percent and there is an actual cost for producing connections. Now, the connection reliability - 

0 99995 and the connection weight ~ 0.5. As a result of the 0 5 connection weight, only one fully cross-strapped 
architecture (architecture 1) is among the optimal architectures much different than the scenario where connection 
weight - 0. The other optimal architectures have just three or four connections From these, architectures 2 and 3 are 
the most interesting. Bach has three sensors and two computers with two of the sensors having one connection to a 
computer and the last having two. 

The connection weight - 0.5 scenario still has quite a hil in common with the connection weight - 0 scenario. 
Once again, the component types in the optimal architectures are predominantly of type A and never of type C. Only 
one optimal architecture (architecture 3) contains a component of type B and this component is again a computer. 
This architecture is no longer optimal when the dissimilar components penalty is increased to penally - 6. There is 
no change in optimal architectures for connection weight _ 0.5 when this penalty is increased from penalty = 6 to 
penalty - 9. 

Figure 1 I depicts the first scenario where connection reliability 0.9999 and connection weight 5/3. This 
scenario produces very similar optimal architectures to the connection weight = 0.5 scenario, but there are some 
notable exceptions. 

Even with the dissimilar components penalty set to penalty - 0, connection weight " 5/3 is sufficiently high as to 
eliminate any architecture that contains a component type heavier than type A. This means that architecture 3 from 
Figure 10, the only connection weight 0.5 architecture which contains a component of type B. is not an optimal 
architecture for connection weight ~~ 5/3. This also means that the optimal architectures for connection weight = 5/3 
will not change if the dissimilar components penalty is increased to penalty 7 ~ 6 or penalty - 9. 

A connection weight of SI 3 also makes it significantly more desirable to have architectures with even fewer 
connections. Although optimal architectures 1, 2, and 4 from Figure 10 are still optimal architectures when the 
connection weight is increased to 5/3, the value of these architectures is diminished with the heavier connection 
weight. As a result, these architectures are no longer significantly closer to the utopia point than architectures 1, 2, 
and 4 from Figure 1 1 . 

The six potentially optimal architectures for connection weight = 5/3 produce an interesting set. All legal 
architectures with four or fewer connections that contain two to three sensors of type A and two computers of type A 
are optimal architectures for this scenario, in effect a system architect is directly trading an increase in weight for 
additional reliability when connection weight - 5/3- 

When reviewing a subset of all the possible architectures, specifically a subset in which all members have the 
same number of connections, the effect of the dissimilar components penalty on the optimal architectures of the 
subset is nearly identical to the penalty's effect on the optimal architectures of the superset. Figures 12 and 13 depict 
the optimal architectures for 3 x 2 systems with 1, 2, 3, 4, 5, 6, l t 8 r and 9 connections w ? hen connection reliability = 

1 and connection weight - 0 (the reliabilities and weights for these architectures can be found in Tables 6 through 
8), Again, as the penalty is increased from penalty' ^ 0 to penalty ~~ 6, nearly all architectures containing sensor type 
B or computer type B cease to be optimal. Note that, for architectures with the same number of connections, the 
exact same architectures which are optimal for penalty 0 will be optimal no matter what the connection weight. 
Similarly, architectures which are optimal Tor penally 6 or penalty 9 will also remain optimal no matter what the 
connection weight. The reasoning goes as follows. Although the overall system weight of any member of a subset 
will change if the connection weight is changed, this change will be identical to the change seen by any of the other 
systems in this subset This is because all systems in each subset have, by definition, the same number of 
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connections. Therefore , among architectures with the same number of connection s, the architectures closest to the 
utopia point will remain closest to the utopia point no matter what change is made to the connection weight. 

Table 6, The reliabilities and weights For the I-, 2-, 3-, 4-, 5-, 6-„ 7-, 8> and 9-connection architectures closest 
the utopia point given a 3 x 2 system with connection reliability = 1, connection weight = 0, and no penalty for 
dissim liar components. 


Connections 

Reliability 

Weight 

On Pareto front? 

1 

0.999100405 

14 



0.999300345 

19 


2 

G. 999993 766 

12 



0.999995260 

14 



0.999996397 

16 



0.999997344 

19 



0.999997754 

20 



0.99999X292 

22 



0.999998741 

25 


3 

0.999995260 

12 



0.999996756 

14 



0.999997499 

15 



0.999998996 

17 



0.999999984 

IS 


4 

0.999996754 

12 

YES 


0.999998993 

15 



0.999999594 

17 



0.999999988 

18 


5 

0 .999998995 

15 



0.999999596 

17 



0.999999992 

18 


6 

0.99999X99% 

15 

YES 


0.999999597 

17 

YES 


0.999999996 

18 


7 

0.999999994 

18 


8 

0.999999996 

18 


9 

0.999999996 

18 

YES 
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Figure 12, The architectures described in Table 6. 

Table 7, The reliabilities and weights for the I-, 2-, 3-, 4-, 5-, 6-, 7-, 8-, and 9-connection architectures closest 
the utopia point given a 3 x 2 system with connection reliability = 1, connection weight = 0, and penalty = 6 
for dissimilar components. 


Connections 

Reliability 

Weight 

On Pareto front? 

1 

0.999100405 

14 



0.999300245 

19 


2 

0.999993766 

12 



0.999996397 

16 


3 

0.999995260 

12 



0.999997499 

15 



0.999999984 

18 


4 

0.999996754 

12 

YES 


0.999998993 

15 



0.999999988 

IS 


5 

0.999998995 

15 



0.999999992 

IS 


6 

0.999998998 

15 

YES 


0.999999996 

IS 


7 

0.999999994 

18 


8 

0.999999996 

IS 


9 

0.999999996 

IS 

YES 
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Figure 13, The architectures described in Tuble 7. 

VIL Conclusion 

If the only materials on hand were sensors of low-reliability type A, computers of low-reliability type A, and 
generic connections, it is still possible to produce nearly all potentially optimal architectures, t he identified optimal 
architectures show this and, more generally, that it is preferable to increase redundancy of lighter, less reliable 
components rather than to use smaller numbers of more reliable, heavy components. 

Due to the extremely lightweight nature of “sensor A” and “computer A", these component types appeared in the 
optimal architectures in every scenario and almost always with redundancy > = 2. Furthermore, the very heavy yet 
very reliable “sensor C* 7 and “computer C” never appeared as an optimal architecture in any scenario, not even with 
redundancy = I. 


NESC Request No. :06-074-I 


# 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

06-074 

Version: 

1.0 

Title: 

System Architectural Considerations on Reliable 
Guidance, Navigation, and Control (GN&C) for 
Constellation Program (CxP) Spacecraft 

Page #: 

67 of 88 


At a certain point, there are diminishing returns to adding redundancy, conn ec Lions, or components with greater 
reliability the system starts to experience only minimal increases in overall reliability for the large gains in weight. 
This faet becomes more apparent through the use of the connection weight penalty* Looking at the optimal 
architectures in each scenario, the number of connections drops dramatically as the connection Weight penalty is 
increased from connection weight - 0 to connection weight ~ 0.5. When connection weight ~~ 0, there are, as 
expected, optimal architectures with as many as nine connections. When connection weight increases to 0.5 
however* this number drops to three or lour 

The impact of the "dissimilar components penalty" is more subtle, but still apparent In the scenarios where 
connection weight - 0 and connection weight - 0.5, architectures containing both computer type A and computer 
type B were identified as potentially optimal when the penalty - 0. However, when the penalty is increased to 
penalty - 6, these architectures no longer appear to be better than other architectures, 

The created OPN models the building blocks of a GN&C system. Now that the base model is complete, more 
delail can gradually be added until the entire system is encapsulated. First, the OPN language should be made more 
efficient, so it does not. run out of memory when trying to run the 3 x 3 model. Next* other architectural layouts 
should be investigated in which the component redundancy for any component can be greater than three. In order to 
do so* however, the process of eliminating duplicates and creating rules (whieh was done by hand) should be 
automated. Also, it is important that more than three types of sensors, computers, and actuators be incorporated into 
the model and that further details be included for each component. For example* requirements might suggest that a 
system needs six degrees-of-freedom of attitude and position knowledge This requirement cannot be addressed with 
the current top-lev el mentality. Finally, further metrics besides reliability and weight should be implemented in the 
model. 

Having such a model in place in OPN would serve as an excellent tool for system design. System requirements 
may dictate a given reliability and such a model would easily be able to find the lowest weight/lowest cost option for 
that reliability. Although less likely, if, rather than overall reliability, the system requirement called for a certain 
number of connections between adjacent components, ihe OPN model could easily find the optimal high 
re liability /low weight option for this architecture as well. 

In addition to reliability, OPN can be made to find the best option for satisfying other metrics as these metrics 
arc added to the model. As additional component redundancy and component types arc added to the mode], all 
possible architectures could eventually be both enumerated and evaluated by OPN. 

A detailed consideration of the findings in this paper could be extremely beneficial Lo the development of the 
CxFs robotic and human-rated systems; clearly exploring commonality in GN&C components can reduce both 
nonrecurring and recurring cost and risk 
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Appendix C. Study Summary Presentation 
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Task Description 


- Analyze different architectural approaches for fault 
tolerance in Lunar GN&C systems 


- Determine if performance goals can be met for 
different levels of reliability by combining like 
components in different architectures 


- Implementing this model in the Object Process 
Network (OPN) modeling language in order to: 

- More easily enumerate and evaluate all possible architectures 

- Ultimately find those architectures that are most optimal in 
terms of architecture, performance and proxy for development 
cost 
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What is OPN? 


• OPN is a visual and computable metalanguage that assists with 
systems architecting tasks. 



• OPN is used to: 


- Describe and Partition space of architectural alternatives. 

- Generate and Enumerate the set of instances of feasible system 
models. 


- Simulate and Order the performance metrics of each model. 


• OPN is a network (a directed graph) of objects and processes 
connected by relationships 
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Motivation for the Use of OPN 


* OPN allows an engineer to systematically explore the architecture space 

- Gives confidence, as entire space is mapped 

- Modeling process often provides insights 

- Allows team to keep options open: no need to trim decision tree early 

* Combines visual representation on Pareto plot with mathematical modeling 

* Easy to add new options to understand the effect of new technologies, 

different configurations 


i ■■ v ■%! w ■ VV 
* ■■ — t- ■ * * ‘f. 

V, - ■ ' -v*,'.' _ ;*■ • T**: 

* « *, 

n - ■ ■ + ♦*- *+ >1 * i 

* • * >-■ ** if *v*t**if 


1 “* *»** * 

4, 

> *t»* Itf 


Performance 


w 

o 

o 

sU 


Applicable to many “levels” of 
architecture 

- Fleet architecture of ships, 
aircraft, radars, missiles 

- Missile architecture of 
propulsion modules, seeker 
heads, data 

- Propulsion architecture of 
propellants, staging, sizing 
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Systems Architecture via OPN 


- Systems architecting using OPN is a three-step 
process: 

. Define a set of rules to generate a valid architecture 
(encoding) 

. Enumerate all possible system architectures 
(enumerating) 

. Evaluate the performance of these architectures in 
terms of metrics (evaluating) 
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1) Encoding 


• GN&C systems can be broken down into simple subunits : 

- Sensors 

- Computers 

- Actuators 

- Interconnections between components 



RULES FOR ARCHITECTURE 
GENERATION: 

* Use 3 kinds of elements (sensors, 
computers and/or actuators)] 

* Use up to 3 sensors / computers / 
actuators 

* Use 3 different types of sensors, 
computers and actuators: A, B, C 

* Use all the feasible interconnections 
between these elements 


sensors computers 


actuators 
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2) Enumerating 


- How many possibilities for sensors? CR 4{ABC0} 3 -1= 20-1 = 19 : 

{A,B,C 1 AA,BB,CC,AB,AC,BC,AAA, AAB, AAC CCC} 

- Obviously the same possibilities for computers: 19 

- How many possible interconnections between sensors and 
computers? 

» Sensor i can be connected to: {Cl; C2; C3; Cl and C2; C2 and C3; 

Cl and C3; or Cl , C2 and C3} THEN 7x7x7=243 

- 19x1 9x243= 87,723 possible architectures for the 3x2 system 

- 19x243x19x243x19= 405,017,091 possible architectures for the 
3x3 system! 

- Not all of these architectures are feasible, as some components 
are not connected, and some patterns are duplicates. Rules have 
been developed to eliminate these cases. 



| Sensor T~ 
I Ssnsor 2 
| Sensor 3 


] — ^Contpiierll 

Y— |C0fflf>tf1&r 21 


- |CoffiputeT3l 


A 

A 

A 



B C 
C C 
C c 
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3) Evaluating 


• Two metrics were used for evaluating performance in this 
study: 

- Reliability as a performance metrics (benefit) 

- Mass as a first order approximation to development cost, and to 
recurring and launch cost 

* The reliability is calculated taking into account the reliabilities of 
the elements (sensors, computers and interconnections) and 
how they are connected. 

• The mass of the architecture is calculated as the sum of the 
masses of all its elements (sensors, computers and 
interconnections)! 

* Additional “mass” penalties were assessed for use of dissimilar 
components for actuators, sensors and processors 


• The use of OPN allows automatic evaluation of each 
enumerated architecture, which helps the architect identify the 
most optimal ones. 
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3) Evaluating 


Reliability of a of a component Reliability of a sensor-computer link: 
(sensor, computer). R1 = Prob (0 fails of sensor AND 0 fails of 

R=Prob (0 fails of component in t interconnection AND 0 fails of computer 
years) = e _M =s. c 1 or LTPoisson in t years) = 
distribution) 


Reliability of a 2x2 system Reliability of a 2x2 system (cross- 
(channelized) strapped): 


R= Prob (0 fails of link 1 OR 0 fails 
of link 2 in t years) = s 1 i^ i e 1 + 

S 2‘22 C 2 ' S 1*11 C 1 S 2*22 C 2 


S l*11 C l, + . S l'l2 C 2 ~ S lil|'l? C iCj + S2i2^C|^' 

S 2*2^ C 2, - S 2*2i*22 C l C 2 - . S 1?2 I 11*2J C 1 - S 1. S 2 1 .11 *22 C 1 ^2 - 
S 1 S 2 1 U , 21 C 1 C 2 + S 1 S 2 1 J1 1 12 1 ?1 C 1 C 2 + S 1 S 2 l ll , ;i , 32 C l‘ C 2 

- S l S 2*t2*22®2 , + S 1 S 2 I J1 , 12 , 22 C J C 2 + S 1 S 2 1 12 , 2! I 22 C 1 C 2 

— S 1 S 2*11 I 12 1 21 1 22 C 1 C 2 
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Values used for analysis 


Sensor Type 

A 

B 

c 

Failure Kate X (/year) 

0.00015 

0.0001 

0.00005 

Reliability R 

0.9985 

0.999 

0.9995 

Weight (dimensionless) 

3 

6 

9 


Computer Type 

A 

B 

C 

Failure Rate X (/year) 

0.0001 

0.00004 

0.00002 

Reliability R 

0.999 

0.9996 

0.9998 

Weight (dimensionless) 

3 

5 

10 


OPN Scenario 

1 

2 

3 

4 

5 

6 

7 

8 

9 

Connection 

Reliability 

1 

1 

1 

0.99995 

0.99995 

0.99995 

0.9999 

0.9999 

0,9999 

Connection 

Weight 

(dimensionless) 

0 

0 

0 

0.5 

0.5 

0.5 

5/3 

5/3 

5/3 

Dissimilar 

Component 

Penalty 

(dimensionless) 

0 

6 

9 

0 

6 

9 

0 

6 

9 


10 
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Results for the ideal case 
(i jk =1,CW=0, DCP=0J 
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Subset Overview of Results 


• For the case shown on the previous chart: 

- The connection reliability is 1 

- The connection mass (CW) is zero 

- The dissimilar component penalty (DCP) is zero 

• All identified desirable architectures are fully cross-strapped 

- Additional connections increase reliability yet cost nothing (in terms for 
added weight) 

• Component weights play a major role in determining the 
optimality of the architecture 

- Even though components of type “A" are the least reliable, sensors of 
type A and computers of type A are by far the most prevalent 
component types in all the optimal architectures 

- Components of type “C” are the most reliable, yet no components of 
this type appear in any of the optimal architectures 

- Architecture 3 contains a computer of type B, but this architecture is 
no longer optimal once the “dissimilar components penalty” (DCP) is 
increased from penalty = 0 to penalty = 6 
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Results for a realistic case 
(ijk = 0.99995, CW = 0.5, DCP = 6J| 
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Results for More Realistic Case 


• The case on the previous chart now has finite reliability of connections, 
finite mass for connections, and a penalty for dissimilary components 

• The effect of the dissimilar components penalty on the optimal 
architectures of specific connection reliabilities and weights is nearly 
identical to the penalty’s effect on the optimal architectures of the superset 

• As the penalty is increased from penalty = 0 to penalty = 6, nearly all 
architectures containing sensor type B or computer type B cease to be 
optimal 

• For architectures with the same number of connections, the exact same 
architectures which are optimal for penalty = 0 will be optimal no matter 
what the connection weight 

• For, architectures which are optimal for penalty = 6 will also remain optimal 
no matter what the connection weight 

• Although the overall system weight of any member of a subset will change 
if the connection weight is changed, this change will be identical to the 
change seen by any of the other systems in this subset 
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Conclusions 


• A systematic method of evaluating the architectures of GNC 
systems composed of a limited set of common components and 
connections has been developed. 

• Based on the values chosen in this representative calculation: 

• Most optimal architectures can be created by using only the 
lightest, lowest reliably components 

• It is preferable to increase redundancy of lighter, less reliable 
components rather than to use smaller numbers of more reliable, 
heavy components 

• There are diminishing returns to adding redundancy, 
connections, or components with greater reliability - the system 
starts to experience only minimal increases in overall reliability 
for the large gains in weight 

• For optimal architectures in each scenario, the number of 
connections drops dramatically as the connection weight penalty 
is increased 

• Dissimilar component penalty has a strong effect of 
homogenizing the architecture 
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Recommendations for Future 
Investigation/Assessment 


• Find a more efficient method of determining the 
reliability of a complex architecture 

• Look at other GN&C architectural layouts: 4 sensor, 3 
computer, 2 actuators (for example^ 

• Include more metrics in the analysis: performance, 
cost, power, degrees of freedom control and sensing, 
etc 
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Backup Charts 
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3) Evaluating 


• The goal is to model cost and complexity through weight. 

• The complexity (and the cost) of the system is higher when it has many 
interconnections but this relationship is not linear. A correction factor was included 
to take into account the increase of complexity due to the number of connections 
connection weight (CW). A CW = 0 means that connections can be added without 
any impact on the global cost and complexity. 

• The weights associated with connections were chosen to be consistent with the 
weights of sensors and computers: 

CW < 1/3 weight of the average computer 

• Analogously, a correction factor was included to take into account the increase of 
complexity when components of different types are used dissimilar component 
penalty. A DCP = 0 means that different types of components can be used without any 
impact on the global cost and complexity. 

W = weight {sensors} + weight {computers} + N* *CW + B* DCP 
where: N is the number of connections 

CW is the connection weight 

B is 0 if all the elements are of the same type and 1 otherwise 

DCP is the dissimilar component penalty 

• The weights associated with DCP were chosen to be consistent with the weights of 
sensors and computers: 

CW £ max weight {sensors, computers} 
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A View of Systems Architecting: 


Systems Architecting starts with “Goals" and 
end with a “Set of Good Solutions” 

- “good” depends on what’s important to 
you 

1st: Decompose the problem 

- Come up with an abstraction that is an 
stable representation of the system 

- This defines the architecture ! 

- In this step, one should figure out the 
abstract processes and objects that are 
always part of the system 

» List the range of specific solutions for 
each object and process 

» This should be kept to a relatively small 
discrete set to start. 
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A View of Systems Architecting: 


2nd: Composing 

- How do the objects and processes 
interact? 

- Specifically, what combinations of specific 
objects and processes make up a valid 
system? 

3rd: Evaluation 

- What are the system metrics? 

» What makes this system “good” for you? 

- Metrics should be a function of the objects 
and processes in your decomposition 

The other “step”: revision 

- As you proceed down this concept of 
architecting, expect to revise the previous 
steps. 
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